@ansvar/eu-regulations-mcp 0.1.0 → 0.2.0

package/data/seed/un-r156.json

@@ -0,0 +1,150 @@
+{
+  "id": "UN_R156",
+  "full_name": "UN Regulation No. 156 - Software update and software update management system",
+  "celex_id": "42021X0388",
+  "effective_date": "2021-01-22",
+  "eur_lex_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:42021X0388",
+  "articles": [
+    {
+      "number": "1",
+      "title": "Scope",
+      "text": "1.1.\n\n1.1.\n\nThis Regulation applies to vehicles of Categories (1) M, N, O, R, S and T that permit software updates.\n\nThis Regulation applies to vehicles of Categories (1) M, N, O, R, S and T that permit software updates."
+    },
+    {
+      "number": "2",
+      "title": "Definitions",
+      "text": "2.1.\n\n2.1.\n\n‘Vehicle type’ means vehicles which do not differ in at least the following:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The manufacturer’s designation of the vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Essential aspects of the design of the vehicle type with respect to software update processes.\n\n‘Vehicle type’ means vehicles which do not differ in at least the following:\n\n(a)\n\n(a)\n\nThe manufacturer’s designation of the vehicle type;\n\nThe manufacturer’s designation of the vehicle type;\n\n(b)\n\n(b)\n\nEssential aspects of the design of the vehicle type with respect to software update processes.\n\nEssential aspects of the design of the vehicle type with respect to software update processes.\n\n2.2.\n\n2.2.\n\n‘RX Software Identification Number (RXSWIN)’ means a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the Regulation No X type approval relevant characteristics of the vehicle.\n\n‘RX Software Identification Number (RXSWIN)’ means a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the Regulation No X type approval relevant characteristics of the vehicle.\n\n2.3.\n\n2.3.\n\n‘Software update’ means a package used to upgrade software to a new version including a change of the configuration parameters.\n\n‘Software update’ means a package used to upgrade software to a new version including a change of the configuration parameters.\n\n2.4.\n\n2.4.\n\n‘Execution’ means the process of installing and activating an update that has been downloaded.\n\n‘Execution’ means the process of installing and activating an update that has been downloaded.\n\n2.5.\n\n2.5.\n\n‘Software Update Management System (SUMS)’ means a systematic approach defining organizational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation.\n\n‘Software Update Management System (SUMS)’ means a systematic approach defining organizational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation.\n\n2.6.\n\n2.6.\n\n‘Vehicle user’ means a person operating or driving the vehicle, a vehicle owner, an authorised representative or employee of a fleet manager, an authorised representative or employee of the vehicle manufacturer, or an authorized technician.\n\n‘Vehicle user’ means a person operating or driving the vehicle, a vehicle owner, an authorised representative or employee of a fleet manager, an authorised representative or employee of the vehicle manufacturer, or an authorized technician.\n\n2.7.\n\n2.7.\n\n‘Safe state’ means an operating mode in case of a failure of an item without an unreasonable level of risk.\n\n‘Safe state’ means an operating mode in case of a failure of an item without an unreasonable level of risk.\n\n2.8.\n\n2.8.\n\n‘Software’ means the part of an Electronic Control System that consists of digital data and instruction.\n\n‘Software’ means the part of an Electronic Control System that consists of digital data and instruction.\n\n2.9.\n\n2.9.\n\n‘Over-the-Air (OTA) update’ means any method of making data transfers wirelessly instead of using a cable or other local connection.\n\n‘Over-the-Air (OTA) update’ means any method of making data transfers wirelessly instead of using a cable or other local connection.\n\n2.10.\n\n2.10.\n\n‘System’ means a set of components and/or sub-systems that implement a function of functions.\n\n‘System’ means a set of components and/or sub-systems that implement a function of functions.\n\n2.11.\n\n2.11.\n\n‘Integrity validation data’ means a representation of digital data, against which comparisons can be made to detect errors or changes in the data. This may include checksums and hash values.\n\n‘Integrity validation data’ means a representation of digital data, against which comparisons can be made to detect errors or changes in the data. This may include checksums and hash values."
+    },
+    {
+      "number": "3",
+      "title": "Application for approval",
+      "text": "3.1.\n\n3.1.\n\nThe application for approval of a vehicle type with regard to software update processes shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\nThe application for approval of a vehicle type with regard to software update processes shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\n3.2.\n\n3.2.\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particulars:\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particulars:\n\n3.3.\n\n3.3.\n\nA description of the vehicle type with regard to the items specified in Annex 1 to this Regulation.\n\nA description of the vehicle type with regard to the items specified in Annex 1 to this Regulation.\n\n3.4.\n\n3.4.\n\nIn cases where information is shown to be covered by intellectual property rights or to constitute specific know-how of the manufacturer or of their suppliers, the manufacturer or their suppliers shall make available sufficient information to enable the checks referred to in this Regulation to be made properly. Such information shall be treated on a confidential basis.\n\nIn cases where information is shown to be covered by intellectual property rights or to constitute specific know-how of the manufacturer or of their suppliers, the manufacturer or their suppliers shall make available sufficient information to enable the checks referred to in this Regulation to be made properly. Such information shall be treated on a confidential basis.\n\n3.5.\n\n3.5.\n\nThe Certificate of Compliance for Software Update Management System according to paragraph 6 of this Regulation.\n\nThe Certificate of Compliance for Software Update Management System according to paragraph 6 of this Regulation.\n\n3.6.\n\n3.6.\n\nA vehicle representative of the vehicle type to be approved shall be submitted to the Technical Service responsible for conducting approval tests.\n\nA vehicle representative of the vehicle type to be approved shall be submitted to the Technical Service responsible for conducting approval tests.\n\n3.7.\n\n3.7.\n\nDocumentation shall be made available in two parts:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitely discontinued.\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Additional material relevant to the requirements of this regulation may be retained by the manufacturer but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitely discontinued.\n\nDocumentation shall be made available in two parts:\n\n(a)\n\n(a)\n\nThe formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitely discontinued.\n\nThe formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitely discontinued.\n\n(b)\n\n(b)\n\nAdditional material relevant to the requirements of this regulation may be retained by the manufacturer but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitely discontinued.\n\nAdditional material relevant to the requirements of this regulation may be retained by the manufacturer but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitely discontinued."
+    },
+    {
+      "number": "4",
+      "title": "Markings",
+      "text": "4.1.\n\n4.1.\n\nThere shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle conforming to a vehicle type approved under this Regulation an international approval mark consisting of:\n\nThere shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle conforming to a vehicle type approved under this Regulation an international approval mark consisting of:\n\n4.1.1.\n\n4.1.1.\n\nA circle surrounding the Letter ‘E’ followed by the distinguishing number of the country which has granted approval (2).\n\nA circle surrounding the Letter ‘E’ followed by the distinguishing number of the country which has granted approval (2).\n\n4.1.2.\n\n4.1.2.\n\nThe number of this Regulation, followed by the letter ‘R’, a dash and the approval number to the right of the circle described in paragraph 4.1.1 above.\n\nThe number of this Regulation, followed by the letter ‘R’, a dash and the approval number to the right of the circle described in paragraph 4.1.1 above.\n\n4.2.\n\n4.2.\n\nIf the vehicle conforms to a vehicle type approved under one or more other Regulations annexed to the Agreement in the country which has granted approval under this Regulation, the symbol prescribed in paragraph 4.1.1 above need not be repeated; in this case the Regulation and approval numbers and the additional symbols of all the Regulations under which approval has been granted in the country which has granted approval under this Regulation shall be placed in vertical columns to the right of the symbol prescribed in paragraph 4.1.1 above.\n\nIf the vehicle conforms to a vehicle type approved under one or more other Regulations annexed to the Agreement in the country which has granted approval under this Regulation, the symbol prescribed in paragraph 4.1.1 above need not be repeated; in this case the Regulation and approval numbers and the additional symbols of all the Regulations under which approval has been granted in the country which has granted approval under this Regulation shall be placed in vertical columns to the right of the symbol prescribed in paragraph 4.1.1 above.\n\n4.3.\n\n4.3.\n\nThe approval mark shall be clearly legible and shall be indelible.\n\nThe approval mark shall be clearly legible and shall be indelible.\n\n4.4.\n\n4.4.\n\nThe approval mark shall be placed on or close to the vehicle data plate affixed by the Manufacturer.\n\nThe approval mark shall be placed on or close to the vehicle data plate affixed by the Manufacturer.\n\n4.5.\n\n4.5."
+    },
+    {
+      "number": "5",
+      "title": "Approval",
+      "text": "5.1.\n\n5.1.\n\nApproval Authorities shall grant, as appropriate, type approval with regard to software update procedures and processes, only to such vehicle types that satisfy the requirements of this Regulation.\n\nApproval Authorities shall grant, as appropriate, type approval with regard to software update procedures and processes, only to such vehicle types that satisfy the requirements of this Regulation.\n\n5.1.1.\n\n5.1.1.\n\nThe Approval Authority or the Technical Service shall verify by testing a vehicle of the vehicle type that the vehicle manufacturer has implemented the measures they have documented. Tests shall be performed by approval authority or the technical service itself or in collaboration with the vehicle manufacturer by sampling.\n\nThe Approval Authority or the Technical Service shall verify by testing a vehicle of the vehicle type that the vehicle manufacturer has implemented the measures they have documented. Tests shall be performed by approval authority or the technical service itself or in collaboration with the vehicle manufacturer by sampling.\n\n5.2.\n\n5.2.\n\nNotice of approval or of extension or refusal of approval of a vehicle type pursuant to this Regulation shall be communicated to the Parties to the 1958 Agreement which apply this Regulation, by means of a form conforming to the model in Annex 2 to this Regulation.\n\nNotice of approval or of extension or refusal of approval of a vehicle type pursuant to this Regulation shall be communicated to the Parties to the 1958 Agreement which apply this Regulation, by means of a form conforming to the model in Annex 2 to this Regulation.\n\n5.3.\n\n5.3.\n\nApproval Authorities shall not grant any type approval without ensuring that the manufacturer has put in place satisfactory arrangements and procedures to manage properly the software update processes aspects as covered by this regulation.\n\nApproval Authorities shall not grant any type approval without ensuring that the manufacturer has put in place satisfactory arrangements and procedures to manage properly the software update processes aspects as covered by this regulation."
+    },
+    {
+      "number": "6",
+      "title": "Certificate of Compliance for Software Update Management System",
+      "text": "6.1.\n\n6.1.\n\nContracting Parties shall appoint an Approval Authority to carry out the assessment of the manufacturer and to issue a Certificate of Compliance for Software Update Management System.\n\nContracting Parties shall appoint an Approval Authority to carry out the assessment of the manufacturer and to issue a Certificate of Compliance for Software Update Management System.\n\n6.2.\n\n6.2.\n\nAn application for a Certificate of Compliance for Software Update Management System shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\nAn application for a Certificate of Compliance for Software Update Management System shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\n6.3.\n\n6.3.\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particular:\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particular:\n\n6.3.1.\n\n6.3.1.\n\nDocuments describing the Software Update Management System.\n\nDocuments describing the Software Update Management System.\n\n6.3.2.\n\n6.3.2.\n\nA signed declaration using the model as defined in Appendix 1 to Annex 1.\n\nA signed declaration using the model as defined in Appendix 1 to Annex 1.\n\n6.4.\n\n6.4.\n\nIn the context of the assessment, the manufacturer shall declare using the model as defined in Appendix 1 to Annex 1 and demonstrate to the satisfaction of the Approval Authority or its Technical Service that they have the necessary processes to comply with all the requirements for software updates according to this Regulation.\n\nIn the context of the assessment, the manufacturer shall declare using the model as defined in Appendix 1 to Annex 1 and demonstrate to the satisfaction of the Approval Authority or its Technical Service that they have the necessary processes to comply with all the requirements for software updates according to this Regulation.\n\n6.5.\n\n6.5.\n\nWhen this assessment has been satisfactorily completed and in receipt of a signed declaration from the manufacturer according to the model as defined in Appendix 1 to Annex 1, a certificate named Certificate of Compliance for SUMS as described in Annex 4 to this Regulation (hereinafter the Certificate of Compliance for SUMS) shall be granted to the manufacturer.\n\nWhen this assessment has been satisfactorily completed and in receipt of a signed declaration from the manufacturer according to the model as defined in Appendix 1 to Annex 1, a certificate named Certificate of Compliance for SUMS as described in Annex 4 to this Regulation (hereinafter the Certificate of Compliance for SUMS) shall be granted to the manufacturer.\n\n6.6.\n\n6.6.\n\nThe Certificate of Compliance for SUMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn.\n\nThe Certificate of Compliance for SUMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn.\n\n6.7.\n\n6.7.\n\nThe Approval Authority which has granted the Certificate of Compliance for Software Update Management System may at any time verify its continued compliance. The Certificate of Compliance for Software Update Management System may be withdrawn if the requirements laid down in this Regulation are no longer met.\n\nThe Approval Authority which has granted the Certificate of Compliance for Software Update Management System may at any time verify its continued compliance. The Certificate of Compliance for Software Update Management System may be withdrawn if the requirements laid down in this Regulation are no longer met.\n\n6.8.\n\n6.8.\n\nThe manufacturer shall inform the Approval Authority or its Technical Service of any change that will affect the relevance of the Certificate of Compliance for Software Update Management System. After consultation with the manufacturer, the Approval Authority or its Technical Service shall decide whether new checks are necessary.\n\nThe manufacturer shall inform the Approval Authority or its Technical Service of any change that will affect the relevance of the Certificate of Compliance for Software Update Management System. After consultation with the manufacturer, the Approval Authority or its Technical Service shall decide whether new checks are necessary.\n\n6.9.\n\n6.9.\n\nAt the end of the period of validity of the Certificate of Compliance for Software Update Management System, the Approval Authority shall, after a positive assessment, issue a new Certificate of Compliance for Software Update Management System or extends its validity for a further period of three years. The Approval Authority shall issue a new certificate in cases where changes have been brought to the attention of the Approval Authority or its Technical Service and the changes have been positively re-assessed.\n\nAt the end of the period of validity of the Certificate of Compliance for Software Update Management System, the Approval Authority shall, after a positive assessment, issue a new Certificate of Compliance for Software Update Management System or extends its validity for a further period of three years. The Approval Authority shall issue a new certificate in cases where changes have been brought to the attention of the Approval Authority or its Technical Service and the changes have been positively re-assessed.\n\n6.10.\n\n6.10.\n\nExisting vehicle type approvals shall not lose their validity due to the expiration of the manufacturer’s Certificate of Compliance for Software Update Management System.\n\nExisting vehicle type approvals shall not lose their validity due to the expiration of the manufacturer’s Certificate of Compliance for Software Update Management System."
+    },
+    {
+      "number": "7",
+      "title": "Specifications",
+      "text": "7.1.\n\n7.1.\n\nRequirements for the Software Update Management System of the vehicle manufacturer\n\nRequirements for the Software Update Management System of the vehicle manufacturer\n\n7.1.1.\n\n7.1.1.\n\nProcesses to be verified at initial assessment\n\nProcesses to be verified at initial assessment\n\n7.1.1.1.\n\n7.1.1.1.\n\nA process whereby information relevant to this Regulation is documented and securely held at the vehicle manufacturer and can be made available to an Approval Authority or its Technical Service upon request;\n\nA process whereby information relevant to this Regulation is documented and securely held at the vehicle manufacturer and can be made available to an Approval Authority or its Technical Service upon request;\n\n7.1.1.2.\n\n7.1.1.2.\n\nA process whereby information regarding all initial and updated software versions, including integrity validation data, and relevant hardware components of a type approved system can be uniquely identified;\n\nA process whereby information regarding all initial and updated software versions, including integrity validation data, and relevant hardware components of a type approved system can be uniquely identified;\n\n7.1.1.3.\n\n7.1.1.3.\n\nA process whereby, for a vehicle type that has an RXSWIN, information regarding the RXSWIN of the vehicle type before and after an update can be accessed and updated. This shall include the ability to update information regarding the software versions and their integrity validation data of all relevant software for each RXSWIN;\n\nA process whereby, for a vehicle type that has an RXSWIN, information regarding the RXSWIN of the vehicle type before and after an update can be accessed and updated. This shall include the ability to update information regarding the software versions and their integrity validation data of all relevant software for each RXSWIN;\n\n7.1.1.4.\n\n7.1.1.4.\n\nA process whereby, for a vehicle type that has an RXSWIN, the vehicle manufacturer can verify that the software version(s) present on a component of a type approved system are consistent with those defined by the relevant RXSWIN;\n\nA process whereby, for a vehicle type that has an RXSWIN, the vehicle manufacturer can verify that the software version(s) present on a component of a type approved system are consistent with those defined by the relevant RXSWIN;\n\n7.1.1.5.\n\n7.1.1.5.\n\nA process whereby any interdependencies of the updated system with other systems can be identified;\n\nA process whereby any interdependencies of the updated system with other systems can be identified;\n\n7.1.1.6.\n\n7.1.1.6.\n\nA process whereby the vehicle manufacturer is able to identify target vehicles for a software update;\n\nA process whereby the vehicle manufacturer is able to identify target vehicles for a software update;\n\n7.1.1.7.\n\n7.1.1.7.\n\nA process to confirm the compatibility of a software update with the target vehicle(s) configuration before it is issued. This shall include an assessment of the last known software/hardware configuration of the target vehicle(s) for compatibility with the update before it is issued;\n\nA process to confirm the compatibility of a software update with the target vehicle(s) configuration before it is issued. This shall include an assessment of the last known software/hardware configuration of the target vehicle(s) for compatibility with the update before it is issued;\n\n7.1.1.8.\n\n7.1.1.8.\n\nA process to assess, identify and record whether a software update will affect any type approved systems. This shall consider whether the update will impact or alter any of the parameters used to define the systems the update may affect or whether it may change any of the parameters used to type approve those system (as defined in the relevant legislation);\n\nA process to assess, identify and record whether a software update will affect any type approved systems. This shall consider whether the update will impact or alter any of the parameters used to define the systems the update may affect or whether it may change any of the parameters used to type approve those system (as defined in the relevant legislation);\n\n7.1.1.9.\n\n7.1.1.9.\n\nA process to assess, identify and record whether a software update will add, alter or enable any functions that were not present, or enabled, when the vehicle was type approved or alter or disable any other parameters or functions that are defined within legislation. The assessment shall include consideration of whether:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Entries in the information package will need to be modified;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Test results no longer cover the vehicle after modification;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 Any modification to functions on the vehicle will affect the vehicle’s type approval.\n\nA process to assess, identify and record whether a software update will add, alter or enable any functions that were not present, or enabled, when the vehicle was type approved or alter or disable any other parameters or functions that are defined within legislation. The assessment shall include consideration of whether:\n\n(a)\n\n(a)\n\nEntries in the information package will need to be modified;\n\nEntries in the information package will need to be modified;\n\n(b)\n\n(b)\n\nTest results no longer cover the vehicle after modification;\n\nTest results no longer cover the vehicle after modification;\n\n(c)\n\n(c)\n\nAny modification to functions on the vehicle will affect the vehicle’s type approval.\n\nAny modification to functions on the vehicle will affect the vehicle’s type approval.\n\n7.1.1.10.\n\n7.1.1.10.\n\nA process to assess, identify and record if a software update will affect any other system required for the safe and continued operation of the vehicle or if the update will add or alter functionality of the vehicle compared to when it was registered;\n\nA process to assess, identify and record if a software update will affect any other system required for the safe and continued operation of the vehicle or if the update will add or alter functionality of the vehicle compared to when it was registered;\n\n7.1.1.11.\n\n7.1.1.11.\n\nA process whereby the vehicle user is able to be informed about updates;\n\nA process whereby the vehicle user is able to be informed about updates;\n\n7.1.1.12.\n\n7.1.1.12.\n\nA process whereby the vehicle manufacturer shall be able to make the information according to paragraph 7.1.2.3 and 7.1.2.4 available to responsible Authorities or the Technical Services. This may be for the purpose of type approval, conformity of production, market surveillance, recalls and Periodic Technical Inspection (PTI).\n\nA process whereby the vehicle manufacturer shall be able to make the information according to paragraph 7.1.2.3 and 7.1.2.4 available to responsible Authorities or the Technical Services. This may be for the purpose of type approval, conformity of production, market surveillance, recalls and Periodic Technical Inspection (PTI).\n\n7.1.2.\n\n7.1.2.\n\nThe vehicle manufacturer shall record, and store, the following information for each update applied to a given vehicle type:\n\nThe vehicle manufacturer shall record, and store, the following information for each update applied to a given vehicle type:\n\n7.1.2.1.\n\n7.1.2.1.\n\nDocumentation describing the processes used by the vehicle manufacturer for software updates and any relevant standards used to demonstrate their compliance;\n\nDocumentation describing the processes used by the vehicle manufacturer for software updates and any relevant standards used to demonstrate their compliance;\n\n7.1.2.2.\n\n7.1.2.2.\n\nDocumentation describing the configuration of any relevant type approved systems before and after an update, this shall include unique identification for the type approved system’s hardware and software (including software versions) and any relevant vehicle or system parameters;\n\nDocumentation describing the configuration of any relevant type approved systems before and after an update, this shall include unique identification for the type approved system’s hardware and software (including software versions) and any relevant vehicle or system parameters;\n\n7.1.2.3.\n\n7.1.2.3.\n\nFor every RXSWIN, there shall be an auditable register describing all the software relevant to the RXSWIN of the vehicle type before and after an update. This shall include information of the software versions and their integrity validation data for all relevant software for each RXSWIN.\n\nFor every RXSWIN, there shall be an auditable register describing all the software relevant to the RXSWIN of the vehicle type before and after an update. This shall include information of the software versions and their integrity validation data for all relevant software for each RXSWIN.\n\n7.1.2.4.\n\n7.1.2.4.\n\nDocumentation listing target vehicles for the update and confirmation of the compatibility of the last known configuration of those vehicles with the update.\n\nDocumentation listing target vehicles for the update and confirmation of the compatibility of the last known configuration of those vehicles with the update.\n\n7.1.2.5.\n\n7.1.2.5.\n\nDocumentation for all software updates for that vehicle type describing:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The purpose of the update;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 What systems or functions of the vehicle the update may affect;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 Which of these are type approved (if any);\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (d)\n                              \n                              \n                                 If applicable, whether the software update affects the fulfilment of any of the relevant requirements of those type approved system;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (e)\n                              \n                              \n                                 Whether the software update affects any system type approval parameter;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (f)\n                              \n                              \n                                 Whether an approval for the update was sought from an approval body;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (g)\n                              \n                              \n                                 How the update may be executed and under what conditions;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (h)\n                              \n                              \n                                 Confirmation that the software update will be conducted safely and securely;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (i)\n                              \n                              \n                                 Confirmation that the software update has undergone and successfully passed verification and validation procedures.\n\nDocumentation for all software updates for that vehicle type describing:\n\n(a)\n\n(a)\n\nThe purpose of the update;\n\nThe purpose of the update;\n\n(b)\n\n(b)\n\nWhat systems or functions of the vehicle the update may affect;\n\nWhat systems or functions of the vehicle the update may affect;\n\n(c)\n\n(c)\n\nWhich of these are type approved (if any);\n\nWhich of these are type approved (if any);\n\n(d)\n\n(d)\n\nIf applicable, whether the software update affects the fulfilment of any of the relevant requirements of those type approved system;\n\nIf applicable, whether the software update affects the fulfilment of any of the relevant requirements of those type approved system;\n\n(e)\n\n(e)\n\nWhether the software update affects any system type approval parameter;\n\nWhether the software update affects any system type approval parameter;\n\n(f)\n\n(f)\n\nWhether an approval for the update was sought from an approval body;\n\nWhether an approval for the update was sought from an approval body;\n\n(g)\n\n(g)\n\nHow the update may be executed and under what conditions;\n\nHow the update may be executed and under what conditions;\n\n(h)\n\n(h)\n\nConfirmation that the software update will be conducted safely and securely;\n\nConfirmation that the software update will be conducted safely and securely;\n\n(i)\n\n(i)\n\nConfirmation that the software update has undergone and successfully passed verification and validation procedures.\n\nConfirmation that the software update has undergone and successfully passed verification and validation procedures.\n\n7.1.3.\n\n7.1.3.\n\nSecurity – the vehicle manufacturer shall demonstrate:\n\nSecurity – the vehicle manufacturer shall demonstrate:\n\n7.1.3.1.\n\n7.1.3.1.\n\nThe process they will use to ensure that software updates will be protected to reasonably prevent manipulation before the update process is initiated;\n\nThe process they will use to ensure that software updates will be protected to reasonably prevent manipulation before the update process is initiated;\n\n7.1.3.2.\n\n7.1.3.2.\n\nThe update processes used are protected to reasonably prevent them being compromised, including development of the update delivery system;\n\nThe update processes used are protected to reasonably prevent them being compromised, including development of the update delivery system;\n\n7.1.3.3.\n\n7.1.3.3.\n\nThe processes used to verify and validate software functionality and code for the software used in the vehicle are appropriate.\n\nThe processes used to verify and validate software functionality and code for the software used in the vehicle are appropriate.\n\n7.1.4.\n\n7.1.4.\n\nAdditional requirements for software updates over the air\n\nAdditional requirements for software updates over the air\n\n7.1.4.1.\n\n7.1.4.1.\n\nThe vehicle manufacturer shall demonstrate the processes and procedures they will use to assess that over the air updates will not impact safety, if conducted during driving.\n\nThe vehicle manufacturer shall demonstrate the processes and procedures they will use to assess that over the air updates will not impact safety, if conducted during driving.\n\n7.1.4.2.\n\n7.1.4.2.\n\nThe vehicle manufacturer shall demonstrate the processes and procedures they will use to ensure that, when an over the air update requires a specific skilled or complex action, for example recalibrate a sensor post-programming, in order to complete the update process, the update can only proceed when a person skilled to do that action is present or is in control of the process.\n\nThe vehicle manufacturer shall demonstrate the processes and procedures they will use to ensure that, when an over the air update requires a specific skilled or complex action, for example recalibrate a sensor post-programming, in order to complete the update process, the update can only proceed when a person skilled to do that action is present or is in control of the process.\n\n7.2.\n\n7.2.\n\nRequirements for the Vehicle Type\n\nRequirements for the Vehicle Type\n\n7.2.1.\n\n7.2.1.\n\nRequirements for Software updates\n\nRequirements for Software updates\n\n7.2.1.1.\n\n7.2.1.1.\n\nThe authenticity and integrity of software updates shall be protected to reasonably prevent their compromise and reasonably prevent invalid updates.\n\nThe authenticity and integrity of software updates shall be protected to reasonably prevent their compromise and reasonably prevent invalid updates.\n\n7.2.1.2.\n\n7.2.1.2.\n\nWhere a vehicle type uses RXSWIN:\n\nWhere a vehicle type uses RXSWIN:\n\n7.2.1.2.1.\n\n7.2.1.2.1.\n\nEach RXSWIN shall be uniquely identifiable. When type approval relevant software is modified by the vehicle manufacturer, the RXSWIN shall be updated if it leads to a type approval extension or to a new type approval.\n\nEach RXSWIN shall be uniquely identifiable. When type approval relevant software is modified by the vehicle manufacturer, the RXSWIN shall be updated if it leads to a type approval extension or to a new type approval.\n\n7.2.1.2.2.\n\n7.2.1.2.2.\n\nEach RXSWIN shall be easily readable in a standardized way via the use of an electronic communication interface, at least by the standard interface (OBD port).\n                     If RXSWINs are not held on the vehicle, the manufacturer shall declare the software version(s) of the vehicle or single ECUs with the connection to the relevant type approvals to the Approval Authority. This declaration shall be updated each time the declared software version(s) is updated. In this case, the software version(s) shall be easily readable in a standardized way via the use of an electronic communication interface, at least by the standard interface (OBD port).\n\nEach RXSWIN shall be easily readable in a standardized way via the use of an electronic communication interface, at least by the standard interface (OBD port).\n\nIf RXSWINs are not held on the vehicle, the manufacturer shall declare the software version(s) of the vehicle or single ECUs with the connection to the relevant type approvals to the Approval Authority. This declaration shall be updated each time the declared software version(s) is updated. In this case, the software version(s) shall be easily readable in a standardized way via the use of an electronic communication interface, at least by the standard interface (OBD port).\n\n7.2.1.2.3.\n\n7.2.1.2.3.\n\nThe vehicle manufacturer shall protect the RXSWINs and/or software version(s) on a vehicle against unauthorised modification. At the time of Type Approval, the means implemented to protect against unauthorized modification of the RXSWIN and/or software version(s) chosen by the vehicle manufacturer shall be confidentially provided.\n\nThe vehicle manufacturer shall protect the RXSWINs and/or software version(s) on a vehicle against unauthorised modification. At the time of Type Approval, the means implemented to protect against unauthorized modification of the RXSWIN and/or software version(s) chosen by the vehicle manufacturer shall be confidentially provided.\n\n7.2.2.\n\n7.2.2.\n\nAdditional Requirements for over the air updates\n\nAdditional Requirements for over the air updates\n\n7.2.2.1.\n\n7.2.2.1.\n\nThe vehicle shall have the following functionality with regards to software updates:\n\nThe vehicle shall have the following functionality with regards to software updates:\n\n7.2.2.1.1.\n\n7.2.2.1.1.\n\nThe vehicle manufacturer shall ensure that the vehicle is able to restore systems to their previous version in case of a failed or interrupted update or that the vehicle can be placed into a safe state after a failed or interrupted update.\n\nThe vehicle manufacturer shall ensure that the vehicle is able to restore systems to their previous version in case of a failed or interrupted update or that the vehicle can be placed into a safe state after a failed or interrupted update.\n\n7.2.2.1.2.\n\n7.2.2.1.2.\n\nThe vehicle manufacturer shall ensure that software updates can only be executed when the vehicle has enough power to complete the update process (including that needed for a possible recovery to the previous version or for the vehicle to be placed into a safe state).\n\nThe vehicle manufacturer shall ensure that software updates can only be executed when the vehicle has enough power to complete the update process (including that needed for a possible recovery to the previous version or for the vehicle to be placed into a safe state).\n\n7.2.2.1.3.\n\n7.2.2.1.3.\n\nWhen the execution of an update may affect the safety of the vehicle, the vehicle manufacturer shall demonstrate how the update will be executed safely. This shall be achieved through technical means that ensures the vehicle is in a state where the update can be executed safely.\n\nWhen the execution of an update may affect the safety of the vehicle, the vehicle manufacturer shall demonstrate how the update will be executed safely. This shall be achieved through technical means that ensures the vehicle is in a state where the update can be executed safely.\n\n7.2.2.2.\n\n7.2.2.2.\n\nThe vehicle manufacturer shall demonstrate that the vehicle user is able to be informed about an update before the update is executed. The information made available shall contain:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The purpose of the update. This could include the criticality of the update and if the update is for recall, safety and/or security purposes;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Any changes implemented by the update on vehicle functions;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 The expected time to complete execution of the update;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (d)\n                              \n                              \n                                 Any vehicle functionalities which may not be available during the execution of the update;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (e)\n                              \n                              \n                                 Any instructions that may help the vehicle user safely execute the update;\n                              \n                           \n                        \n                     \n                     In case of groups of updates with a similar content one information may cover a group.\n\nThe vehicle manufacturer shall demonstrate that the vehicle user is able to be informed about an update before the update is executed. The information made available shall contain:\n\n(a)\n\n(a)\n\nThe purpose of the update. This could include the criticality of the update and if the update is for recall, safety and/or security purposes;\n\nThe purpose of the update. This could include the criticality of the update and if the update is for recall, safety and/or security purposes;\n\n(b)\n\n(b)\n\nAny changes implemented by the update on vehicle functions;\n\nAny changes implemented by the update on vehicle functions;\n\n(c)\n\n(c)\n\nThe expected time to complete execution of the update;\n\nThe expected time to complete execution of the update;\n\n(d)\n\n(d)\n\nAny vehicle functionalities which may not be available during the execution of the update;\n\nAny vehicle functionalities which may not be available during the execution of the update;\n\n(e)\n\n(e)\n\nAny instructions that may help the vehicle user safely execute the update;\n\nAny instructions that may help the vehicle user safely execute the update;\n\nIn case of groups of updates with a similar content one information may cover a group.\n\n7.2.2.3.\n\n7.2.2.3.\n\nIn the situation where the execution of an update whilst driving may not be safe, the vehicle manufacturer shall demonstrate how they will:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Ensure the vehicle cannot be driven during the execution of the update;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Ensure that the driver is not able to use any functionality of the vehicle that would affect the safety of the vehicle or the successful execution of the update.\n\nIn the situation where the execution of an update whilst driving may not be safe, the vehicle manufacturer shall demonstrate how they will:\n\n(a)\n\n(a)\n\nEnsure the vehicle cannot be driven during the execution of the update;\n\nEnsure the vehicle cannot be driven during the execution of the update;\n\n(b)\n\n(b)\n\nEnsure that the driver is not able to use any functionality of the vehicle that would affect the safety of the vehicle or the successful execution of the update.\n\nEnsure that the driver is not able to use any functionality of the vehicle that would affect the safety of the vehicle or the successful execution of the update.\n\n7.2.2.4.\n\n7.2.2.4.\n\nAfter the execution of an update the vehicle manufacturer shall demonstrate how the following will be implemented:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The vehicle user is able to be informed of the success (or failure) of the update;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 The vehicle user is able to be informed about the changes implemented and any related updates to the user manual (if applicable).\n\nAfter the execution of an update the vehicle manufacturer shall demonstrate how the following will be implemented:\n\n(a)\n\n(a)\n\nThe vehicle user is able to be informed of the success (or failure) of the update;\n\nThe vehicle user is able to be informed of the success (or failure) of the update;\n\n(b)\n\n(b)\n\nThe vehicle user is able to be informed about the changes implemented and any related updates to the user manual (if applicable).\n\nThe vehicle user is able to be informed about the changes implemented and any related updates to the user manual (if applicable).\n\n7.2.2.5.\n\n7.2.2.5.\n\nThe vehicle shall ensure that preconditions have to be met before the software update is executed.\n\nThe vehicle shall ensure that preconditions have to be met before the software update is executed."
+    },
+    {
+      "number": "8",
+      "title": "Modification of vehicle type and extension of type approval",
+      "text": "8.1.\n\n8.1.\n\nEvery modification of the vehicle type which affects its technical performance and/or documentation required in this Regulation shall be notified to the approval authority which granted the approval. The approval authority may then either:\n\nEvery modification of the vehicle type which affects its technical performance and/or documentation required in this Regulation shall be notified to the approval authority which granted the approval. The approval authority may then either:\n\n8.1.1.\n\n8.1.1.\n\nConsider that the modifications made still comply with the requirements and documentation of prior type approval; or\n\nConsider that the modifications made still comply with the requirements and documentation of prior type approval; or\n\n8.1.2.\n\n8.1.2.\n\nRequire a further test report from the Technical Service responsible for conducting the tests.\n\nRequire a further test report from the Technical Service responsible for conducting the tests.\n\n8.1.3.\n\n8.1.3.\n\nConfirmation or extension or refusal of approval, specifying the alterations, shall be communicated by means of a communication form conforming to the model in Annex 2 to this Regulation. The approval authority issuing the extension of approval shall assign a series number for such an extension and inform there of the other Parties to the 1958 Agreement applying this Regulation by means of a communication form conforming to the model in Annex 2 to this Regulation.\n\nConfirmation or extension or refusal of approval, specifying the alterations, shall be communicated by means of a communication form conforming to the model in Annex 2 to this Regulation. The approval authority issuing the extension of approval shall assign a series number for such an extension and inform there of the other Parties to the 1958 Agreement applying this Regulation by means of a communication form conforming to the model in Annex 2 to this Regulation."
+    },
+    {
+      "number": "9",
+      "title": "Conformity of production",
+      "text": "9.1.\n\n9.1.\n\nThe Conformity of Production Procedures shall comply with those set out in the 1958 Agreement, Schedule 1 (E/ECE/TRANS/505/Rev.3) with the following requirements:\n\nThe Conformity of Production Procedures shall comply with those set out in the 1958 Agreement, Schedule 1 (E/ECE/TRANS/505/Rev.3) with the following requirements:\n\n9.1.1.\n\n9.1.1.\n\nThe holder of the approval shall ensure that results of the conformity of production tests are recorded and that the annexed documents remain available for a period determined in agreement with the Approval Authority or its Technical Service. This period shall not exceed 10 years counted from the time when production is definitively discontinued;\n\nThe holder of the approval shall ensure that results of the conformity of production tests are recorded and that the annexed documents remain available for a period determined in agreement with the Approval Authority or its Technical Service. This period shall not exceed 10 years counted from the time when production is definitively discontinued;\n\n9.1.2.\n\n9.1.2.\n\nThe Approval Authority which has granted type approval may at any time verify the conformity control methods applied in each production facility. The normal frequency of these verifications shall be once every three years.\n\nThe Approval Authority which has granted type approval may at any time verify the conformity control methods applied in each production facility. The normal frequency of these verifications shall be once every three years.\n\n9.1.3.\n\n9.1.3.\n\nThe Approval Authority or its Technical Service shall periodically validate that the processes used and decisions made by the vehicle manufacturer are compliant, particularly for instances where the vehicle manufacturer chose not to notify the Approval Authority or its Technical Service about an update. This may be achieved on a sampling basis.\n\nThe Approval Authority or its Technical Service shall periodically validate that the processes used and decisions made by the vehicle manufacturer are compliant, particularly for instances where the vehicle manufacturer chose not to notify the Approval Authority or its Technical Service about an update. This may be achieved on a sampling basis."
+    },
+    {
+      "number": "10",
+      "title": "Penalties for non-conformity of production",
+      "text": "10.1.\n\n10.1.\n\nThe approval granted in respect of a vehicle type pursuant to this Regulation may be withdrawn if the requirement laid down in this Regulation are not complied with or if sample vehicles fail to comply with the requirements of this Regulation.\n\nThe approval granted in respect of a vehicle type pursuant to this Regulation may be withdrawn if the requirement laid down in this Regulation are not complied with or if sample vehicles fail to comply with the requirements of this Regulation.\n\n10.2.\n\n10.2.\n\nIf an Approval Authority withdraws an approval it has previously granted, it shall forthwith so notify the Contracting Parties applying this Regulation, by means of a communication form conforming to the model in Annex 2 to this Regulation.\n\nIf an Approval Authority withdraws an approval it has previously granted, it shall forthwith so notify the Contracting Parties applying this Regulation, by means of a communication form conforming to the model in Annex 2 to this Regulation."
+    },
+    {
+      "number": "11",
+      "title": "Production definitively discontinued",
+      "text": "11.1.\n\n11.1.\n\nIf the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this Regulation, he shall so inform the authority which granted the approval. Upon receiving the relevant communication that authority shall inform thereof the other Contracting Parties to the Agreement applying this Regulation by means of a copy of the approval form bearing at the end, in large letters, the signed and dated annotation ‘PRODUCTION DISCONTINUED’.\n\nIf the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this Regulation, he shall so inform the authority which granted the approval. Upon receiving the relevant communication that authority shall inform thereof the other Contracting Parties to the Agreement applying this Regulation by means of a copy of the approval form bearing at the end, in large letters, the signed and dated annotation ‘PRODUCTION DISCONTINUED’."
+    },
+    {
+      "number": "12",
+      "title": "Names and addresses of Technical Services responsible for conducting approval tests, and of Type Approval Authorities",
+      "text": "12.1.\n\n12.1.\n\nThe Contracting Parties to the Agreement which apply this Regulation shall communicate to the United Nations Secretariat the names and addresses of the Technical Services responsible for conducting approval tests and of the Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or withdrawal of approval, issued in other countries, are to be sent.\n\nThe Contracting Parties to the Agreement which apply this Regulation shall communicate to the United Nations Secretariat the names and addresses of the Technical Services responsible for conducting approval tests and of the Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or withdrawal of approval, issued in other countries, are to be sent.\n\n(1)  As defined in the Consolidated Resolution on the Construction of Vehicles (R.E.3.), document ECE/TRANS/WP.29/78/Rev.6, para. 2 - www.unece.org/trans/main/wp29/wp29wgs/wp29gen/wp29resolutions.html\n\n(2)  The distinguishing numbers of the Contracting Parties to the 1958 Agreement are reproduced in Annex 3 to the Consolidated Resolution on the Construction of Vehicles (R.E.3), document ECE/TRANS/WP.29/78/Rev.6."
+    },
+    {
+      "number": "Annex 1",
+      "title": "Information document",
+      "text": "Information document\n\nInformation document\n\nThe following information, if applicable, shall be supplied in triplicate and include a list of contents. Any drawings shall be supplied in appropriate scale and in sufficient detail on size A4 or on a folder of A4 format. Photographs, if any, shall show sufficient detail.\n\n1.\n\nMake (trade name of manufacturer): …\n\nMake (trade name of manufacturer): …\n\n2.\n\nType and general commercial description(s): …\n\n(Type is the type to be approved, commercial description refers to the product in which the approved type is used)\n\n3.\n\nMeans of identification of type, if marked on the vehicle: …\n\nMeans of identification of type, if marked on the vehicle: …\n\n4.\n\nLocation of that marking: …\n\nLocation of that marking: …\n\n5.\n\nCategory(ies) of vehicle: …\n\nCategory(ies) of vehicle: …\n\n6.\n\nName and address of manufacturer/manufacturer's representative: …\n\nName and address of manufacturer/manufacturer's representative: …\n\n7.\n\nName(s) and Address(es) of assembly plant(s): …\n\nName(s) and Address(es) of assembly plant(s): …\n\n8.\n\nPhotograph(s) and/or drawing(s) of a representative vehicle: …\n\nPhotograph(s) and/or drawing(s) of a representative vehicle: …\n\n9.\n\nSoftware Updates\n\nSoftware Updates\n\n9.1.\n\nGeneral construction characteristics of the vehicle type: …\n\nGeneral construction characteristics of the vehicle type: …\n\n9.2.\n\nThe number of the Certificate of Compliance for Software Update Management System: …\n\nThe number of the Certificate of Compliance for Software Update Management System: …\n\n9.3.\n\nSecurity measures.\n\nSecurity measures.\n\n9.3.1.\n\nDocuments for the vehicle type to be approved describing that the update process will be performed securely …\n\nDocuments for the vehicle type to be approved describing that the update process will be performed securely …\n\n9.3.2.\n\nDocuments for the vehicle type to be approved describing that the RXSWINs on a vehicle are protected against unauthorized manipulation …\n\nDocuments for the vehicle type to be approved describing that the RXSWINs on a vehicle are protected against unauthorized manipulation …\n\n9.4.\n\nSoftware updates over the air\n\nSoftware updates over the air\n\n9.4.1.\n\nDocuments for the vehicle type to be approved describing that the update process will be performed safely…\n\nDocuments for the vehicle type to be approved describing that the update process will be performed safely…\n\n9.4.2.\n\nHow a vehicle user is able to be informed about an update before and after its execution. …\n\nHow a vehicle user is able to be informed about an update before and after its execution. …",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 2",
+      "title": "Communication",
+      "text": "Communication\n\n(Maximum format: A4 (210 × 297 mm))\n\n(1)\n\nissued by:\n\nissued by:\n\nName of administration:\n                        …\n                        …\n                        …\n\nName of administration:\n\nConcerning (2):\n\nConcerning (2):\n\nApproval granted\n                        Approval extended\n                        Approval withdrawn with effect from dd/mm/yyyy\n                        Approval refused\n                        Production definitively discontinued\n\nApproval granted\n\nApproval extended\n\nApproval withdrawn with effect from dd/mm/yyyy\n\nApproval refused\n\nProduction definitively discontinued\n\nof a vehicle type, pursuant to UN Regulation No 156\n\nApproval No: …\n\nExtension No: …\n\nReason for extension: …\n\n1.\n\nMake (trade name of manufacturer): …\n\nMake (trade name of manufacturer): …\n\n2.\n\nType and general commercial description(s) …\n\nType and general commercial description(s) …\n\n3.\n\nMeans of identification of type, if marked on the vehicle: …\n\nMeans of identification of type, if marked on the vehicle: …\n\n3.1.\n\nLocation of that marking: …\n\nLocation of that marking: …\n\n4.\n\nCategory(ies) of vehicle: …\n\nCategory(ies) of vehicle: …\n\n5.\n\nName and address of manufacturer/manufacturer’s representative: …\n\nName and address of manufacturer/manufacturer’s representative: …\n\n6.\n\nName(s) and Address(es) of the production plant(s) …\n\nName(s) and Address(es) of the production plant(s) …\n\n7.\n\nNumber of the certificate of compliance for software update management system: …\n\nNumber of the certificate of compliance for software update management system: …\n\n8.\n\nSoftware updates over the air included (yes/no): …\n\nSoftware updates over the air included (yes/no): …\n\n9.\n\nTechnical Service responsible for carrying out the tests: …\n\nTechnical Service responsible for carrying out the tests: …\n\n10.\n\nDate of test report: …\n\nDate of test report: …\n\n11.\n\nNumber of test report: …\n\nNumber of test report: …\n\n12.\n\nRemarks: (if any) …\n\nRemarks: (if any) …\n\n13.\n\nPlace: …\n\nPlace: …\n\n14.\n\nDate: …\n\nDate: …\n\n15.\n\nSignature: …\n\nSignature: …\n\n16.\n\nThe index to the information package lodged with the Approval Authority, which may be obtained on request is attached.\n\nThe index to the information package lodged with the Approval Authority, which may be obtained on request is attached.\n\n(1)  Distinguishing number of the country which has granted/extended/refused/withdrawn approval (see marking provisions (footnote) in this Regulation).\n\n(2)  Strike out what does not apply.",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 3",
+      "title": "Arrangements of the approval mark",
+      "text": "Arrangement of approval mark\n\nArrangement of approval mark\n\nMODEL A\n\n(See paragraph 4.2 of this Regulation)\n\na = 8 mm min.\n\nThe above approval mark affixed to a vehicle shows that the road vehicle type concerned has been approved in the Netherlands (E 4), pursuant to Regulation No 156, and under the approval number 001234. The first two digits of the approval number indicate that the approval was granted in accordance with the requirements of this Regulation in its original form (00).",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 4",
+      "title": "Certificate of Compliance for SUMS",
+      "text": "Model of Certificate of Compliance for Software Update Management System\n\nModel of Certificate of Compliance for Software Update Management System\n\nCertificate of Compliance for Software Update Management System\n\nwith UN Regulation No 156\n\nCertificate Number [Reference number]\n\nReference number\n\n[……. Approval Authority]\n\nApproval Authority\n\nCertifies that\n\nManufacturer: …\n\nAddress of the manufacturer: …\n\nComplies with the provisions of Regulation No 156\n\nVerifications have been performed on: …\n\nby (name and address of the Approval Authority): …\n\nNumber of report: …\n\nThe certificate is valid until: [………………………………………………Date]\n\nDate\n\nDone at: [……………………………………Place]\n\nPlace\n\nOn: [……………………………………Date]\n\nDate\n\n[…………………………………………………Signature]\n\nSignature",
+      "chapter": "Annexes"
+    }
+  ],
+  "definitions": [
+    {
+      "term": "vehicle type",
+      "definition": "vehicles which do not differ in at least the following: (a) The manufacturer's designation of the vehicle type; (b) Essential aspects of the design of the vehicle type with respect to software update processes. 'Vehicle type' means vehicles which do not differ in at least the following: (a) (a) The manufacturer's designation of the vehicle type; The manufacturer's designation of the vehicle type; (b) (b) Essential aspects of the design of the vehicle type with respect to software update processes. Essential aspects of the design of the vehicle type with respect to software update processes",
+      "article": "2"
+    },
+    {
+      "term": "rx software identification number (rxswin)",
+      "definition": "a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the Regulation No X type approval relevant characteristics of the vehicle. 'RX Software Identification Number (RXSWIN)' means a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the Regulation No X type approval relevant characteristics of the vehicle",
+      "article": "2"
+    },
+    {
+      "term": "software update",
+      "definition": "a package used to upgrade software to a new version including a change of the configuration parameters. 'Software update' means a package used to upgrade software to a new version including a change of the configuration parameters",
+      "article": "2"
+    },
+    {
+      "term": "execution",
+      "definition": "the process of installing and activating an update that has been downloaded. 'Execution' means the process of installing and activating an update that has been downloaded",
+      "article": "2"
+    },
+    {
+      "term": "software update management system (sums)",
+      "definition": "a systematic approach defining organizational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation. 'Software Update Management System (SUMS)' means a systematic approach defining organizational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation",
+      "article": "2"
+    },
+    {
+      "term": "vehicle user",
+      "definition": "a person operating or driving the vehicle, a vehicle owner, an authorised representative or employee of a fleet manager, an authorised representative or employee of the vehicle manufacturer, or an authorized technician. 'Vehicle user' means a person operating or driving the vehicle, a vehicle owner, an authorised representative or employee of a fleet manager, an authorised representative or employee of the vehicle manufacturer, or an authorized technician",
+      "article": "2"
+    },
+    {
+      "term": "safe state",
+      "definition": "an operating mode in case of a failure of an item without an unreasonable level of risk. 'Safe state' means an operating mode in case of a failure of an item without an unreasonable level of risk",
+      "article": "2"
+    },
+    {
+      "term": "software",
+      "definition": "the part of an Electronic Control System that consists of digital data and instruction. 'Software' means the part of an Electronic Control System that consists of digital data and instruction",
+      "article": "2"
+    },
+    {
+      "term": "over-the-air (ota) update",
+      "definition": "any method of making data transfers wirelessly instead of using a cable or other local connection. 'Over-the-Air (OTA) update' means any method of making data transfers wirelessly instead of using a cable or other local connection",
+      "article": "2"
+    },
+    {
+      "term": "system",
+      "definition": "a set of components and/or sub-systems that implement a function of functions. 'System' means a set of components and/or sub-systems that implement a function of functions",
+      "article": "2"
+    },
+    {
+      "term": "integrity validation data",
+      "definition": "a representation of digital data, against which comparisons can be made to detect errors or changes in the data. This may include checksums and hash values. 'Integrity validation data' means a representation of digital data, against which comparisons can be made to detect errors or changes in the data. This may include checksums and hash values",
+      "article": "2"
+    }
+  ]
+}

package/dist/http-server.d.ts

@@ -0,0 +1,9 @@
+#!/usr/bin/env node
+/**
+ * HTTP Server Entry Point for Smithery Hosted Deployment
+ *
+ * This provides Streamable HTTP transport for remote MCP clients.
+ * Use src/index.ts for local stdio-based usage.
+ */
+export {};
+//# sourceMappingURL=http-server.d.ts.map

package/dist/http-server.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"http-server.d.ts","sourceRoot":"","sources":["../src/http-server.ts"],"names":[],"mappings":";AAEA;;;;;GAKG"}

package/dist/http-server.js

@@ -0,0 +1,342 @@
+#!/usr/bin/env node
+/**
+ * HTTP Server Entry Point for Smithery Hosted Deployment
+ *
+ * This provides Streamable HTTP transport for remote MCP clients.
+ * Use src/index.ts for local stdio-based usage.
+ */
+import { createServer } from 'node:http';
+import { Server } from '@modelcontextprotocol/sdk/server/index.js';
+import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
+import { CallToolRequestSchema, ListToolsRequestSchema, } from '@modelcontextprotocol/sdk/types.js';
+import Database from 'better-sqlite3';
+import { fileURLToPath } from 'url';
+import { dirname, join } from 'path';
+import { randomUUID } from 'crypto';
+import { searchRegulations } from './tools/search.js';
+import { getArticle } from './tools/article.js';
+import { listRegulations } from './tools/list.js';
+import { compareRequirements } from './tools/compare.js';
+import { mapControls } from './tools/map.js';
+import { checkApplicability } from './tools/applicability.js';
+import { getDefinitions } from './tools/definitions.js';
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+// Database path - look for regulations.db in data folder
+const DB_PATH = process.env.EU_COMPLIANCE_DB_PATH || join(__dirname, '..', 'data', 'regulations.db');
+// HTTP server port
+const PORT = parseInt(process.env.PORT || '3000', 10);
+let db;
+function getDatabase() {
+    if (!db) {
+        try {
+            db = new Database(DB_PATH, { readonly: true });
+        }
+        catch (error) {
+            throw new Error(`Failed to open database at ${DB_PATH}: ${error}`);
+        }
+    }
+    return db;
+}
+// Create MCP server instance
+function createMcpServer() {
+    const server = new Server({
+        name: 'eu-regulations-mcp',
+        version: '0.1.0',
+    }, {
+        capabilities: {
+            tools: {},
+        },
+    });
+    // Define available tools
+    server.setRequestHandler(ListToolsRequestSchema, async () => ({
+        tools: [
+            {
+                name: 'search_regulations',
+                description: 'Search across all EU regulations for articles matching a query. Returns relevant articles with snippets highlighting matches.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        query: {
+                            type: 'string',
+                            description: 'Search query (e.g., "incident reporting", "personal data breach")',
+                        },
+                        regulations: {
+                            type: 'array',
+                            items: { type: 'string' },
+                            description: 'Optional: filter to specific regulations (e.g., ["GDPR", "NIS2"])',
+                        },
+                        limit: {
+                            type: 'number',
+                            description: 'Maximum results to return (default: 10)',
+                        },
+                    },
+                    required: ['query'],
+                },
+            },
+            {
+                name: 'get_article',
+                description: 'Retrieve the full text of a specific article from a regulation.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        regulation: {
+                            type: 'string',
+                            description: 'Regulation ID (e.g., "GDPR", "NIS2", "DORA")',
+                        },
+                        article: {
+                            type: 'string',
+                            description: 'Article number (e.g., "17", "23")',
+                        },
+                    },
+                    required: ['regulation', 'article'],
+                },
+            },
+            {
+                name: 'list_regulations',
+                description: 'List available regulations and their structure. Without parameters, lists all regulations. With a regulation specified, shows chapters and articles.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        regulation: {
+                            type: 'string',
+                            description: 'Optional: specific regulation to get detailed structure for',
+                        },
+                    },
+                },
+            },
+            {
+                name: 'compare_requirements',
+                description: 'Compare requirements across multiple regulations on a specific topic. Useful for understanding differences in how regulations address similar concerns.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        topic: {
+                            type: 'string',
+                            description: 'Topic to compare (e.g., "incident reporting", "risk assessment")',
+                        },
+                        regulations: {
+                            type: 'array',
+                            items: { type: 'string' },
+                            description: 'Regulations to compare (e.g., ["DORA", "NIS2"])',
+                        },
+                    },
+                    required: ['topic', 'regulations'],
+                },
+            },
+            {
+                name: 'map_controls',
+                description: 'Map security framework controls to EU regulation requirements. Shows which articles satisfy specific security controls.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        framework: {
+                            type: 'string',
+                            enum: ['ISO27001', 'NIST_CSF'],
+                            description: 'Control framework: ISO27001 (ISO 27001:2022) or NIST_CSF (NIST Cybersecurity Framework)',
+                        },
+                        control: {
+                            type: 'string',
+                            description: 'Optional: specific control ID (e.g., "A.5.1" for ISO27001, "PR.AC-1" for NIST CSF)',
+                        },
+                        regulation: {
+                            type: 'string',
+                            description: 'Optional: filter mappings to specific regulation',
+                        },
+                    },
+                    required: ['framework'],
+                },
+            },
+            {
+                name: 'check_applicability',
+                description: 'Determine which EU regulations apply to an organization based on sector and characteristics.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        sector: {
+                            type: 'string',
+                            enum: ['financial', 'healthcare', 'energy', 'transport', 'digital_infrastructure', 'public_administration', 'manufacturing', 'other'],
+                            description: 'Organization sector',
+                        },
+                        subsector: {
+                            type: 'string',
+                            description: 'Optional: more specific subsector (e.g., "bank", "insurance" for financial)',
+                        },
+                        member_state: {
+                            type: 'string',
+                            description: 'Optional: EU member state (ISO country code)',
+                        },
+                        size: {
+                            type: 'string',
+                            enum: ['sme', 'large'],
+                            description: 'Optional: organization size',
+                        },
+                    },
+                    required: ['sector'],
+                },
+            },
+            {
+                name: 'get_definitions',
+                description: 'Look up official definitions of terms from EU regulations. Terms are defined in each regulation\'s definitions article.',
+                inputSchema: {
+                    type: 'object',
+                    properties: {
+                        term: {
+                            type: 'string',
+                            description: 'Term to look up (e.g., "personal data", "incident", "processing")',
+                        },
+                        regulation: {
+                            type: 'string',
+                            description: 'Optional: filter to specific regulation',
+                        },
+                    },
+                    required: ['term'],
+                },
+            },
+        ],
+    }));
+    // Handle tool calls
+    server.setRequestHandler(CallToolRequestSchema, async (request) => {
+        const { name, arguments: args } = request.params;
+        try {
+            const database = getDatabase();
+            switch (name) {
+                case 'search_regulations': {
+                    const input = args;
+                    const results = await searchRegulations(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(results, null, 2) }],
+                    };
+                }
+                case 'get_article': {
+                    const input = args;
+                    const article = await getArticle(database, input);
+                    if (!article) {
+                        return {
+                            content: [{ type: 'text', text: `Article ${input.article} not found in ${input.regulation}` }],
+                            isError: true,
+                        };
+                    }
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(article, null, 2) }],
+                    };
+                }
+                case 'list_regulations': {
+                    const input = (args ?? {});
+                    const result = await listRegulations(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+                    };
+                }
+                case 'compare_requirements': {
+                    const input = args;
+                    const result = await compareRequirements(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+                    };
+                }
+                case 'map_controls': {
+                    const input = args;
+                    const result = await mapControls(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+                    };
+                }
+                case 'check_applicability': {
+                    const input = args;
+                    const result = await checkApplicability(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+                    };
+                }
+                case 'get_definitions': {
+                    const input = args;
+                    const result = await getDefinitions(database, input);
+                    return {
+                        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+                    };
+                }
+                default:
+                    return {
+                        content: [{ type: 'text', text: `Unknown tool: ${name}` }],
+                        isError: true,
+                    };
+            }
+        }
+        catch (error) {
+            return {
+                content: [{ type: 'text', text: `Error: ${error instanceof Error ? error.message : String(error)}` }],
+                isError: true,
+            };
+        }
+    });
+    return server;
+}
+// Start HTTP server with Streamable HTTP transport
+async function main() {
+    const mcpServer = createMcpServer();
+    // Map to store transports by session ID
+    const transports = new Map();
+    const httpServer = createServer(async (req, res) => {
+        const url = new URL(req.url || '/', `http://localhost:${PORT}`);
+        // Health check endpoint
+        if (url.pathname === '/health') {
+            res.writeHead(200, { 'Content-Type': 'application/json' });
+            res.end(JSON.stringify({ status: 'ok', server: 'eu-regulations-mcp' }));
+            return;
+        }
+        // MCP endpoint
+        if (url.pathname === '/mcp') {
+            // Get or create session
+            const sessionId = req.headers['mcp-session-id'];
+            let transport;
+            if (sessionId && transports.has(sessionId)) {
+                // Reuse existing transport for this session
+                transport = transports.get(sessionId);
+            }
+            else {
+                // Create new transport with session ID generator
+                transport = new StreamableHTTPServerTransport({
+                    sessionIdGenerator: () => randomUUID(),
+                });
+                // Connect MCP server to transport
+                await mcpServer.connect(transport);
+                // Store transport by session ID once it's assigned
+                transport.onclose = () => {
+                    if (transport.sessionId) {
+                        transports.delete(transport.sessionId);
+                    }
+                };
+            }
+            // Handle the request
+            await transport.handleRequest(req, res);
+            // Store transport if new session was created
+            if (transport.sessionId && !transports.has(transport.sessionId)) {
+                transports.set(transport.sessionId, transport);
+            }
+            return;
+        }
+        // 404 for other paths
+        res.writeHead(404, { 'Content-Type': 'application/json' });
+        res.end(JSON.stringify({ error: 'Not found' }));
+    });
+    httpServer.listen(PORT, () => {
+        console.error(`EU Regulations MCP server (HTTP) listening on port ${PORT}`);
+        console.error(`MCP endpoint: http://localhost:${PORT}/mcp`);
+        console.error(`Health check: http://localhost:${PORT}/health`);
+    });
+    // Graceful shutdown
+    process.on('SIGTERM', () => {
+        console.error('Received SIGTERM, shutting down...');
+        httpServer.close(() => {
+            if (db)
+                db.close();
+            process.exit(0);
+        });
+    });
+}
+main().catch((error) => {
+    console.error('Fatal error:', error);
+    process.exit(1);
+});
+//# sourceMappingURL=http-server.js.map