A method and a tool for generating a safety case for a safety-critical product

Abstract

A continuous integration tool for generating a safety case for a safety-critical product, wherein the safety-critical product comprises a plurality of product elements, at least a portion of the product elements comprises information expressed using a formalized description language, and said information includes one or more safety case fragments, wherein the continuous integration tool is configured to: 1) receive an updated safety-critical product, where the updated safety-critical product comprises an update introduced to the safety-critical product, and wherein the update comprises an addition, an alteration and / or a removal of one or more product elements, 2) verify consistency and completeness of the updated safety-critical product by validating the information in the product elements and their associated safety case fragments by using the formalized description language, and 3) generate the safety case for the updated safety-critical product based on the information in the product elements, including the update, and all associated safety case fragments.

Description

[0001] A METHOD AND A TOOL FOR GENERATING A SAFETY CASE FOR A SAFETY-CRITICAL PRODUCT

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to safety case generation in a continuous integration and continuous deployment (CI / CD) pipeline. In particular, the disclosure relates to safety case generation for the automotive industry and other sectors where safety is of critical concern.

[0004] BACKGROUND

[0005] Standard practice in the automotive industry is to release new functionality as part of a platform project. Typically, new features are introduced with a start-of-production (SOP) cycle, which occurs every few years. All analyses, especially those concerning the safety case of the product, are connected to the SOP workflow and numerous activities throughout organizations must be adapted to align with the SOP cadence. The same pattern can be observed in other industries, where established tradition involves developing a single product over a span of a few years, while concurrently formulating a comprehensive safety argumentation for this product.

[0006] However, the trend in many industries, including automotive, is to provide new features to the end customers at a higher pace. Having a short time-to-market for new features is a competitive advantage and this applies to both factory-produced features as well as subscription features that can be remotely updated. This method of offering continuous deployment is well-established in some other industries, but what sets the automotive industry apart is that a significant number of its features are safety-critical, and for such products, there are various rules to follow, such as laws, regulations, and international standards.

[0007] A safety case provides a complete argumentation on why a certain product is safe. Any update of the product implies the need for an updated safety case to reflect the latest version of the product. Existing methods for safety case generation have been developed for slower SOP-based cadences and are ill-suited for agile and more frequent deployment, especially for vehicles already in use. Hence, there is a need to provide an improved way of generating a safety case in a higher paced time-to-market environment. SUMMARY

[0008] It is an objective of the present disclosure to provide new improved ways of generating a safety case in a higher paced time-to-market environment. This objective is obtained, at least in part, by a continuous integration tool and a method disclosed herein.

[0009] According to a first aspect of the disclosure, a continuous integration tool for generating a safety case for a safety-critical product is disclosed. The safety-critical product comprises a plurality of product elements, where at least a portion of the product elements comprises information expressed using a formalized description language, and said information includes one or more safety case fragments. The continuous integration tool is configured to receive an updated safety-critical product, where the updated safety-critical product comprises an update introduced to the safety-critical product, and wherein the update comprises an addition, an alteration and / or a removal of one or more product elements. The continuous integration tool is further configured to verify consistency and completeness of the updated safety-critical product by validating the information in the product elements and their associated safety case fragments by using the formalized description language. Lastly, the continuous integration tool is further configured to generate the safety case for the updated safety-critical product based on the information in the product elements, including the update and all associated safety case fragments. The continuous integration tool aims to facilitate frequent and agile deployment of new features, particularly for vehicles that are already in use. A technical benefit may include the enabling of continuous integration of safety-critical features. Another benefit is that it ensures the main branch of product development to remain aligned and consistent with a safety case, which is developed concurrently with the product. Hence, this approach helps prevent safety case gaps, as there is always a valid safety case accompanying each new version of the product. Additional advantages may encompass the parallelization and automation of tasks contributing to the safety case.

[0010] Optionally, in some examples, the continuous integration tool is further configured to receive new evidence referenced in the safety case for the updated safety-critical product, validate all referenced evidence by confirming that the referenced evidence supports the argument which links the evidence to the claim, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion, and publish the safety case and the evidence chain. A technical benefit includes the ability of automatically keeping track of the state of the evidence, which can be seen as a measure of the maturity level of the product, and a clear indicator of whether the current development version of the product is ready for release from a safety case standpoint.

[0011] Optionally, in some examples, the continuous integration tool is further configured to promote the updated safety-critical product to a deployment candidate in a version control system or any other type of release management platform. A technical benefit may include being able to automatically, or at least more rapidly, deploy new features to customers, as any commit that has been flagged as a deployment candidate will already have an associated full safety case.

[0012] Optionally, in some examples, the information expressed using the formalized description language is defined according to a layered hierarchical structure, in which the information comprise a plurality of layers arranged in hierarchical order such that information in any single layer can only reference its own information and the information in its underlying layers. A technical benefit may include ensuring that product elements are easy to reuse, facilitating modularity, due to avoiding unnecessary recursion within the information structure.

[0013] Optionally, in some examples, the layered hierarchical structure comprises a component layer, and wherein the information in the component layer comprises functional and structural information for modeling product elements that comprise system components and their constituent parts such that these elements are possible to individually specify and update independently of their position in a system architecture.

[0014] Optionally, in some examples, the layered hierarchical structure comprises a contract layer (320), and wherein the information in the contract layer comprises all information needed, including contracts, in addition to the information available in the underlying layers, to model safety constraints applicable to the product elements. A technical benefit may include the modular approach to all requirements and dependencies enabling decoupling that allows for a parallelized and automated workflow, which is crucial for continuous integration and continuous deployment.

[0015] Optionally, in some examples, the layered hierarchical structure comprises a verification layer, and wherein the information in the verification layer comprises all information needed, in addition to the information in the underlying layers, to model verification criteria for the contracts.

[0016] Optionally, in some examples, the layered hierarchical structure comprises a realization layer, and wherein the information in the realization layer comprises all information needed, in addition to the information available in the underlying layers, to model the realization of the components and their integration with each other, with respect to the contracts and the verification criteria for the contracts.

[0017] Optionally, in some examples, the layered hierarchical structure comprises an argument fragment layer, and wherein the information in the argument fragment layer comprises all information needed, in addition to the information available in the underlying layers, to model the safety arguments connecting all underlying information into a safety case. A technical benefit may include the use of reusable and modular safety argumentation that fits within the framework of continuous integration and continuous deployment.

[0018] Optionally, in some examples, the layered hierarchical structure comprises a safety case layer, and wherein the information in the safety case layer comprises the structural information detailing how the information available in the underlying layers form the safety case for the safety-critical product.

[0019] According to a second aspect of the disclosure, a method for generating a safety case for a safety-critical product in a continuous integration tool chain is disclosed. The safety-critical product comprises a plurality of product elements, where at least a portion of the product elements comprises information expressed using a formalized description language, and where said information includes one or more safety case fragments. The method comprises introducing an update to the safety-critical product to obtain an updated safety-critical product, wherein the update comprises an addition, an alteration and / or a removal of one or more product elements. The method further comprises verifying consistency and completeness of the updated safety-critical product, wherein verifying comprises validating the information in the product elements, including the update, and their associated safety case fragments by using the formalized description language. Lastly, the method comprises generating the safety case for the updated safety-critical product based on the information in the product elements, including the update, and all associated safety case fragments. The method aims to facilitate frequent and agile deployment of new features, particularly for vehicles that are already in use. A technical benefit may include the enabling of continuous integration of safety-critical features. Another benefit is that it ensures the main branch of product development to remain aligned and consistent with a safety case, which is developed concurrently with the product. Hence, this approach helps prevent safety case gaps, as there is always a valid safety case accompanying each new version of the product. Additional advantages may encompass the parallelization and automation of tasks contributing to the safety case.

[0020] Optionally, in some examples, the method further comprises receiving new evidence referenced in the safety case for the updated safety-critical product, validating all referenced evidence by confirming that the referenced evidence supports the argument which links the evidence to the claim, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion, and publishing the safety case and the evidence chain. A technical benefit includes the ability of automatically keeping track of the state of the evidence, which can be seen as a measure of the maturity level of the product, and a clear indicator of whether the current development version of the product is ready for release from a safety case standpoint.

[0021] Optionally, in some examples, the method further comprises promoting the updated safety- critical product to a deployment candidate in a version control system or any other type of release management platform. A technical benefit may include being able to automatically, or at least more rapidly, deploy new features to customers, as any commit that has been flagged as a deployment candidate will already have an associated full safety case.

[0022] Optionally, in some examples, the information expressed using the formalized description language is defined according to a layered hierarchical structure, in which the information comprise a plurality of layers arranged in hierarchical order such that information in any single layer can only reference its own information and the information in its underlying layers. A technical benefit may include ensuring that product elements are easy to reuse, facilitating modularity, due to avoiding unnecessary recursion within the information structure.

[0023] Optionally, in some examples, the layered hierarchical structure comprises a component layer, and wherein the information in the component layer comprises functional and structural information for modeling product elements that comprise system components and their constituent parts such that these elements are possible to individually specify and update independently of their position in a system architecture.

[0024] Optionally, in some examples, the layered hierarchical structure comprises a contract layer, and wherein the information in the contract layer comprises all information needed, including contracts, in addition to the information available in the underlying layers, to model safety constraints applicable to the product elements. A technical benefit may include the modular approach to all requirements and dependencies enabling decoupling that allows for a parallelized and automated workflow, which is crucial for continuous integration and continuous deployment.

[0025] Optionally, in some examples, the layered hierarchical structure comprises a verification layer, and wherein the information in the verification layer comprises all information needed, in addition to the information in the underlying layers, to model verification criteria for the contracts.

[0026] Optionally, in some examples, the layered hierarchical structure comprises a realization layer, and wherein the information in the realization layer comprises all information needed, in addition to the information available in the underlying layers, to model the realization of the components and their integration with each other, with respect to the contracts and the verification criteria for the contracts.

[0027] Optionally, in some examples, the layered hierarchical structure comprises an argument fragment layer, and wherein the information in the argument fragment layer comprises all information needed, in addition to the information available in the underlying layers, to model the safety arguments connecting all underlying information into a safety case. A technical benefit may include the use of reusable and modular safety argumentation that fits within the framework of continuous integration and continuous deployment.

[0028] Optionally, in some examples, the layered hierarchical structure comprises a safety case layer, and wherein the information in the safety case layer comprises the structural information detailing how the information available in the underlying layers form the safety case for the updated safety-critical product.

[0029] BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above, as well as additional objects, features, and advantages, will be better understood through the following illustrative and non-limiting detailed description of exemplary embodiments, wherein:

[0031] Figure 1 illustrates a continuous integration (Cl) tool chain comprising a version control Cl tool and a Cl tool for generating a safety case for a safety-critical product;

[0032] Figure 2 illustrates an extended continuous integration tool chain comprising a version control Cl tool, a Cl tool for generating a safety case and an evidence chain for a safety-critical product, and a document / artifact storage system;

[0033] Figure 3 illustrates a layered hierarchical structure;

[0034] Figure 4 illustrates a flow chart of a method for generating a safety case for a safety- critical product in a continuous integration pipeline;

[0035] Figure 5 illustrates an optional extension to the method of Figure 4;

[0036] Figure 6A schematically illustrates a processing unit; and

[0037] Figure 6B shows an example computer program product.

[0038] DETAILED DESCRIPTION

[0039] The present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided for thoroughness and completeness. Like reference characters refer to like elements throughout the description.

[0040] A first embodiment relates to a continuous integration tool 102 for generating a safety case 130 for a safety-critical product 110, 110'. The first embodiment is described with reference to Figures 1-3. A second embodiment relates to a method for generating a safety case 130 for a safety-critical product 110, 110' in a continuous integration tool chain 100. The second embodiment is described with reference to Figures 1-5.

[0041] A safety case follows the wide-spread meaning, denoting a structured argument that is founded on evidence that justifies why a particular product, or customer functionality thereof, is considered to be safe in its operation. A safety case covers the full product. A structured argument that is founded on evidence, for only a part of a product, or customer functionality thereof, is denoted a safety case fragment. In this seting, the structured argument comprises a number of claims that are related to each other through asserted evidence, asserted inference and asserted context. It's worth noting that throughout this disclosure, the terminology generally adheres to OMG's Structured Assurance Case Metamodel (SACM).

[0042] The first embodiment, pertaining to the continuous integration tool 102 for developing a safety case 130 for a safety-critical product 110, 110', will be presented in detail in the next sections with reference to Figures 1-3.

[0043] Figure 1 illustrates a continuous integration (Cl) tool chain 100 comprising a version control Cl tool 101 and a Cl tool 102 for generating a safety case for a safety-critical product 110. An update 120 to the safety-critical product may be implemented using the version control Cl tool, bringing about an updated safety-critical product 110'.

[0044] The safety-critical product 110, 110' comprises a plurality of product elements 111A, 111B, 111N, where at least a portion of the product elements comprises information expressed using a formalized description language, and where said information includes one or more safety case fragments. The safety-critical product may comprise one or more non-safety- related product elements, which may resemble safety-related product elements in form but are not associated to one or more safety case fragments. The product elements 111A, 111B, 111N are distinct segments of data or sets of files that comprise information related, directly or indirectly, to the product. This information may include, but is not limited to, safety case fragments, requirements, code, tests, data models, design parameters, functional specifications, configuration parameters, and architectural system descriptions. The product elements 111A, 111B, 111N are interconnected using a formalized description language. This language enables the clear and structured expression of the relationships between the safety case fragments and other product elements, ensuring the possibility of validating the consistency and completeness of the product, as well as the possibility of generating a full safety case 130.

[0045] The Cl tool 102 is configured to receive the updated safety-critical product 110', where the updated safety-critical product 110' comprises the update 120 introduced to the safety- critical product 110, and wherein the update 120 comprises an addition, an alteration and / or a removal of one or more product elements. In other words, the update may be an addition only, an alteration only, a removal only, an addition and an alteration, an addition and a removal, an alteration and a removal, or a combination of an addition, an alteration, and a removal of one or more product elements. An addition of a new product element may, for example, be a new test case that will be automatically run by the continuous integration pipeline, thereby producing new evidence which can be referenced by a safety case fragment. An alteration of an existing product element may, for example, be updated requirements due to adapting the product to a new market. A removal of an existing product element may, for example, be when removing a deprecated feature.

[0046] The Cl tool 102 is further configured to verify consistency and completeness of the updated safety-critical product by validating the information in the product elements and their associated safety case fragments by using the formalized description language. As the information has been expressed using the formalized description language, automatic parsing and validation of the relations between product elements is readily achievable. The formalized description language may be a profile of any standardized modeling language such as UML or SysML, or any domain specific modeling language where the meta-model can also be expressed in its own set of product elements. In other words, the formalized description language may be expressed using a standardized modeling language such as UML or SysML. An example of valid structured information above could be any set of JSON or XML documents that passes a validation given corresponding JSON Schema or XSD documents. An example of invalid structured information above could be any set of JSON or XML documents that fails a validation given corresponding JSON Schema or XSD documents.

[0047] The Cl tool 102 is also configured generate the safety case 130' for the updated safety- critical product 110' based on the information in the product elements, including the update 120 and all associated safety case fragments. Note that the associated safety case fragments comprise all safety case fragments of the product elements that will contribute to the full safety case of the product. The full safety case 130, 130' is generated by integrating all claims from the safety case fragments into a single claim structure. This claim structure is encompassed within the product elements 111A, 111B, 111N and can, therefore, be obtained by parsing and traversing the information of the relationships between the different product elements that has been expressed therein. Since the information has been expressed using a formalized description language the integration can be done by means of an automatic data model transformation in the continuous integration pipeline.

[0048] Figure 2 details an optional extension to the continuous integration tool 102. According to this example, the continuous integration tool 102 may further be configured to receive new evidence 240 referenced in the safety case 130 for the updated safety-critical product 110'. In one example, new evidence 240 may involve evidence that was not existing when the updated safety case 130' was generated, but the evidence 240 was promised to be generated at a later point in time. A piece of evidence is typically an artifact, which can take various forms, including but not limited to a test report, a review record, or field data. As already mentioned, a safety case 130 is a structured argument comprising a number of claims, each supported by evidence.

[0049] The continuous integration tool 102 may further configured validate all referenced evidence by confirming that the referenced evidence supports the argument which links the evidence to the claim, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion. The referenced evidence must support the argument which links the evidence to the claim, this property of the evidence, applicability, can automatically be derived from the context in which its referenced when the evidence has been automatically generated and can be parsed by machine. But when the referenced evidence is of a manual form, for example a manually written test protocol, it is necessary to have an assertion of its applicability in the context of the claim at the time of the update. This also forms the evidence chain: the evidence as an artifact, together with information of the source of the evidence, as well as information regarding the assertion of its applicability, and the source of that assertion.

[0050] An example of referenced evidence that would pass a validation could be a test report from a track test of a tire pressure monitoring system (TPMS) system which shows that the system fulfills the test specification criteria, including information supporting the applicability, for example that the tested software version corresponds to the correct commit, could be considered. An example of referenced evidence that would fail a validation would be if the previous track test report lacked information regarding which version of software that was tested as the applicability would be questionable.

[0051] Next, the continuous integration tool 102 may be configured to publish the safety case 130' and the evidence chain 250. Publishing the safety case and the evidence chain 250. This involves making it available for consumption by interested parties, by for example storing a built safety case together with the validated evidence in a document or artifact storage system 260, such as SAP Document Management System or JFrog Artifactory, as a step in the continuous integration pipeline.

[0052] Figure 2 also details another optional extension to the continuous integration tool 102. According to this example, the continuous integration tool 102 may be further configured to promote the updated safety-critical product 110' to a deployment candidate in a version control system or any other type of release management platform. This can be achieved by merging an associated commit to a main branch, by tagging an associated commit or by using any other feature of the version control system that is meant for this purpose. In this context, an associated commit refers to the specific set of changes or updates made to a safety-critical product's code or configuration. A deployment candidate includes a consistent product together with a complete and valid safety case, where all evidence promises are fulfilled by the evidence artefacts. It should be noted that a valid deployment candidate has to be buildable, which is typically ensured by mechanisms that are traditionally a part of any continuous integration pipeline.

[0053] The second embodiment, relating to the method for generating a safety case 130 for a safety-critical product 110, 110' in a continuous integration tool chain 100, will be presented in detail in the next sections with reference to Figures 1-5.

[0054] Figure 4 illustrates a flow chart of a method, according to a first example, for generating a safety case 130 for a safety-critical product 110, 110' in a continuous integration pipeline. The safety-critical product comprises a plurality of product elements 111A, 111B, 111N, where at least a portion of the product elements comprises information expressed using a formalized description language, and where said information includes one or more safety case fragments. The safety-critical product may also include one or more non-safety-related product elements, which may resemble safety-related product elements in form but are not associated to one or more safety case fragments.

[0055] The product elements 111A, 111B, 111N are distinct segments of data or sets of files that comprise information related, directly or indirectly, to the product. This information may include, but is not limited to, safety case fragments, requirements, code, tests, data models, design parameters, functional specifications, configuration parameters, and architectural system descriptions.

[0056] The product elements 111A, 111B, 111N are interconnected using a formalized description language. This language enables the clear and structured expression of the relationships between the safety case fragments and other product elements, ensuring the possibility of validating the consistency and completeness of the product, as well as the possibility of generating the full safety case 130, 130'.

[0057] The method comprises the steps of introducing SI an update 120, verifying S2 consistency and completeness of the updated safety-critical product 110', and generating S3 the safety case 130' for the updated safety-critical product 110'. Further details on these steps are provided below.

[0058] The method comprises introducing SI an update 120 to the safety-critical product 110 to obtain an updated safety-critical product 110', wherein the update 120 comprises an addition, an alteration and / or a removal of one or more product elements. In other words, the update may be an addition only, an alteration only, a removal only, an addition and an alteration, an addition and a removal, an alteration and a removal, or a combination of an addition, an alteration, and a removal of one or more product elements. An addition of a new product element may, for example, be a new test case that will be automatically run by the continuous integration pipeline, thereby producing new evidence which can be referenced by a safety case fragment. An alteration of an existing product element may, for example, be updated requirements due to adapting the product to a new market. A removal of an existing product element may, for example, be when removing a deprecated feature.

[0059] The method further comprises verifying S2 consistency and completeness of the updated safety-critical product 110', wherein verifying comprises validating the information in the product elements 111A, 111B, 111N, including the update 120, and their associated safety case fragments by using the formalized description language.

[0060] As the information has been expressed using the formalized description language, automatic parsing and validation of the relations between product elements is readily achievable. The formalized description language may be a profile of any standardized modeling language such as UML or SysML, or any domain specific modeling language where the meta-model can also be expressed in its own set of product elements. In other words, the formalized description language may be expressed using a standardized modeling language such as UML or SysML.

[0061] An example of valid structured information could be any set of JSON or XML documents that passes a validation given corresponding JSON Schema or XSD documents. An example of invalid structured information could be any set of JSON or XML documents that fails a validation given corresponding JSON Schema or XSD documents.

[0062] The method also comprises generating S3 the safety case 130' for the updated safety-critical product 110' based on the information in the product elements 111A, 111B, 111N, including the update 120, and all associated safety case fragments. The full safety case 130 is generated by integrating all claims from the safety case fragments into a single claim structure. This claim structure is encompassed within the product elements 111A, 111B, 111N and can, therefore, be obtained by parsing and traversing the information of the relationships between the different product elements that has been expressed therein. Since the information has been expressed using the formalized description language the integration can be done by means of an automatic data model transformation in the continuous integration pipeline.

[0063] Figure 5 illustrates a flowchart of an optional extension to the method of the second embodiment, wherein the optional extension additionally comprises the steps of receiving S4, validating S5, and publishing S6.

[0064] The step of receiving S4 comprises receiving new evidence 240 referenced in the safety case 130' for the updated safety-critical product 110'. In one example, receiving evidence 240 may involve waiting for evidence that was not yet existing at the time of introducing SI the update but was promised to be generated at a later point in time. A piece of evidence is typically an artifact, which can take various forms, including but not limited to a test report, a review record, or field data. As already mentioned, a safety case 130, 130' is a structured argument comprising a number of claims, each supported by evidence.

[0065] The step of validating S5 all referenced evidence comprises confirming that the referenced evidence supports the argument which links the evidence to the claim of the evidence, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion.

[0066] The referenced evidence must support the argument which links the evidence to the claim, this property of the evidence, applicability, can automatically be derived from the context in which its referenced when the evidence has been automatically generated and can be parsed by machine. But when the referenced evidence is of a manual form, for example a manually written test protocol, it is necessary to have an assertion of its applicability in the context of the claim at the time of the update. This also forms the evidence chain: the evidence as an artifact, together with information of the source of the evidence, as well as information regarding the assertion of its applicability, and the source of that assertion.

[0067] An example of referenced evidence that would pass a validation could be a test report from a track test of a tire pressure monitoring system (TPMS) system which shows that the system fulfills the test specification criteria, including information supporting the applicability, for example that the tested software version corresponds to the correct commit, could be considered. An example of referenced evidence that would fail a validation would be if the previous track test report lacked information regarding which version of software that was tested as the applicability would be questionable.

[0068] The method, according to the optional second example, comprises publishing S6 the safety case 130' and the evidence chain 250. This involves making it available for consumption by interested parties, by for example storing a built safety case together with the validated evidence in a document or artifact storage system 260, such as SAP Document Management System or JFrog Artifactory, as a step in the continuous integration pipeline.

[0069] Figure 5 details another optional extension to the method. According to this example, the method may further comprise promoting S7 the updated safety-critical product 110' to a deployment candidate in a version control system or any other type of release management platform. This can be achieved by merging an associated commit to a main branch, by tagging an associated commit or by using any other feature of the version control system that is meant for this purpose. In this context, an associated commit refers to the specific set of changes or updates made to a safety-critical product's code or configuration. A deployment candidate includes a consistent product together with a complete and valid safety case, where all evidence promises are fulfilled by the evidence artefacts. It should be noted that a valid deployment candidate has to be buildable, which is typically ensured by mechanisms that are traditionally a part of any continuous integration pipeline.

[0070] In the following, some aspects pertaining to both the first and second embodiments are described.

[0071] The information expressed using the formalized description language may be defined according to a layered hierarchical structure, in which the information comprise a plurality of layers arranged in hierarchical order such that information in any single layer is only allowed to reference information within itself and in its underlying layers. In this context, the underlying layers are all the layers of lower hierarchy in the layered hierarchical structure 300. Hence, each layer except the lowest layer will have its own set of underlying layers. In one example, a first layer may comprise structural information that describes how product elements 111A, 111B, 111N relate to one another, while a second layer includes the safety case fragments associated with all the product elements.

[0072] Another example of a layered hierarchical structure is provided in Figure 3. The product elements may be modelled according to this layered hierarchical structure, wherein they encompass a plurality of layers arranged in hierarchical order such that information in any single layer is only allowed to reference information in layers of lower hierarchy. The dependency direction in Figure 3 is from top to bottom, indicating that information within any given layer can only reference information in lower layers in the hierarchy. The layered hierarchical structure of Figure 3 provides an example in which the product elements comprise a component layer 310, a contract layer 320, a verification layer 330, a realization layer 340, an argument fragment layer 350, and a safety case layer 350. This layered structure comprises N=6 layers, for which the component layer has lowest hierarchical order (i.e., the bottom layer) and the safety case layer has the highest hierarchical order (i.e., the top layer). The component layer 310, the contract layer 320, the verification layer 330, the realization layer 340, the argument fragment layer 350, and the safety case 360 layer will be described in further detail below.

[0073] The layered hierarchical structure may comprise any number of layers. For example, a layered hierarchical structure arranged into N=2 layers may divide and group the functionality of the component layer, the contract layer, the verification layer, the realization layer, the argument fragment layer, and the safety case layer into a top layer and a bottom layer. The top layer would then comprise at least the functionality of the safety case layer, while the bottom layer would comprise at least the functionality of the component layer. Similarly, one could define the layered hierarchical structure with N=3, 4 and 5 layers, or alternatively N=7 or more layers if further layers are defined. In one example with N=3 layers, the functionality of the component layer, the contract layer and the verification layer may be comprised in a bottom layer, the realization layer may be an intermediate layer, and the functionality of the argument fragment layer and the safety case layer may be a top layer. In the example of Figure 3, the layered hierarchical structure comprises a component layer 310. The information in the component layer comprises functional and structural properties for modeling product elements that comprise system components and their constituent parts, i.e., discrete identifiable information technology assets that represents a building block of a system and may include hardware, software, and firmware. These product elements that comprise system components are possible to individually specify and update. This also applies independently of their position in a system architecture.

[0074] The component layer comprises the basic modeling components for decomposing the overall system design into system components and their pieces, that are individually possible to specify and update. For example, it may comprise functional information, such as descriptions of provided interfaces, functional behavior and functional constraints, and structural information, such as descriptions of component composition, deployment constraints and how components can interact, all describing the system components and their pieces.

[0075] This individual possibility to update also includes architectural design on any level of aggregation, as these are expressed as composed components in a truly decoupled and modular way. The composed (non-atomic) components are not defined as a recursive structure of the contained component. Instead, every composed component has an internal structure that is specified as an internal placeholder connected with delegation connectors. This means that there are no other components that directly and recursively define the structure of a composed component, but only the first level of refinement. These placeholders can at an integration be realized by one or another component, as long as the interfaces and any other constraints are matching. This way of decoupling the component structure is valuable in a CI / CD context where any component should be possible to update with a minimal impact on the entire product.

[0076] In the example of Figure 3, the layered hierarchical structure comprises a contract layer 320. The information in the contract layer comprises all information needed, including contracts, in addition to the information available in the underlying layers 310, to model safety constraints applicable to the product elements 111A, 111B, 111N. The information in the contract layer comprises safety constraints such as contracts that describe the specific conditions under which product elements operates safely and may include the responsibilities of each element in maintaining the overall system safety.

[0077] The contract layer models safety constraints applicable to the product elements by combining the contracts with the functional and structural information of the component layer.

[0078] As the system components that are modelled in the component layer realizes the functionality of the system, and that functionality may be safety related, the safety constraints are modelled in part by relations to the component layer in the contract layer, i.e. imposing a contract on the functionality described in the layer below.

[0079] A component has local contracts, specifying what is assumed and what is guaranteed, to keep track that any realization is valid in the integration context. An example of an assumption could be that a temperature sensor will operate in an environment where the temperature ranges between -25°C to 75°C, and a guarantee could be that the temperature sensor will provide temperature readings with an accuracy of ±0.5°C within the assumed temperature range.

[0080] There is a separation of concern between the dependencies that arise, by prescribing valid contract relations for the different dependency relations. There are four dimensions in which the contracts apply: abstraction, aggregation, allocation, and functional relation.

[0081] The abstraction relation connects firstly the highest abstraction (functional behavior as seen from the outside without internal structural information) with the structural component view. Secondly, the abstraction relation is connecting the component structural view with the real implementation in software in hardware on the lowest level of abstraction. The contracts bridging the abstraction levels are to make sure that the semantics of the corresponding safety requirements is compatible such that it is possible to build together a complete and consistent chain of rationale arguments in the layers building the safety case.

[0082] For example, in a vehicle's navigation system, an abstract contract might specify that the system provides the current location within a 10-meter accuracy without detailing the GPS and sensor technologies used to achieve this. This abstraction allows for changes in underlying technologies without affecting the overall system functionality guaranteed by the contract.

[0083] The aggregation contracts take advantage of the component layer for aggregation constituting the complex components, i.e. referring to how individual components or functionalities are combined to form a larger system or subsystem. Composed and atomic components all have contracts related to their external interface. The composed components also have contracts related to the internal placeholders. The contract relation in a composition then becomes the relation between the contract of the placeholder in the composed component and the contract of the external interface of the component defined to fulfil the placeholder during the integration.

[0084] For example, for a battery pack in an electric vehicle, an aggregation contract could define how individual battery cells' performance and safety features aggregate to meet the overall battery pack's performance requirements, including total energy capacity and safety mechanisms during failure conditions.

[0085] The allocation contracts are about the relation between an application component and the platform component it is allocated to. These are important to handle separately as it is a typical CI / CD use case to move application components between platform components.

[0086] For example, in a distributed computing system, an allocation contract might specify the memory and processing power allocated to each service within the system. For instance, a high-priority data analysis service is guaranteed a minimum of 16GB of RAM and four CPU cores, ensuring performance requirements are met under the system's operational conditions.

[0087] The functional relation contracts are the ones that come as a result of connecting contracts on external interfaces with each other, which is often the only aspect covered when speaking about contracts.

[0088] For example, in an adaptive cruise control system, a functional relation contract might stipulate how the radar system's detection of a preceding vehicle (input) guarantees the automatic adjustment of the vehicle's speed (output) to maintain a safe following distance. This contract defines the functional dependencies and interactions between the radar and speed control modules.

[0089] The contracts are structured explicitly in the mentioned four dimensions, which makes it well suited for continuous changes as is the case in CI / CD.

[0090] The component can be modelled without the contracts, but the contracts cannot be modelled without referencing the specific component and interfaces they apply to.

[0091] In the example of Figure 3, the layered hierarchical structure comprises a verification layer 330. The information in the verification layer 330 comprises all information needed, in addition to the information in the underlying layers 310, 320, to model verification criteria for the contracts. The purpose of this layer is to capture the information necessary to understand how the contracts are verified, i.e., the verification criteria.

[0092] The information in the verification layer comprises structural information on how the contracts are verified. This may include information such as whether verification is conducted through analysis or by test, whether verification tests are integrated into the Cl chain itself, and whether field data is incorporated into the verification process, among other factors. The verification layer describes the verification of the contracts. Hence, it represents a one-directional dependency with respect to the contract layer. It is possible to specify requirements for a component on the contract layer without knowledge of its verification, but when modeling a verification, it is necessary to indicate which specifications it fulfills. Thus, the verification layer models verification criteria by combining the structural information on how the contracts are verified with the contracts.

[0093] In the example of Figure 3, the layered hierarchical structure comprises a realization layer 340. The information in the realization layer 330 comprises all information needed, in addition to the information available in the underlying layers 310, 320, 330, to model the realization of the components and their integration with each other, with respect to the contracts and the verification criteria for the contracts.

[0094] The information in the realization layer comprises relational information between product elements, i.e., a representation of how modelled information in the product elements are interconnected. The realization layer models the realization of the components and their integration with each other, with respect to contracts and their verification criteria by combining the relational information with the information across component, contract, and verification layers. Or alternatively, the component, contract, and verification structures from lower layers are used in combination with the relational information to model the realization of the components and their integration with each other.

[0095] The realization layer describes the realization of the components, which are specified by the contracts and with a verification method according to the verification layer. Hence, this is also a one-directional dependency. It is possible to specify the requirements for a component on the contract layer and the verification on the verification layer without knowing anything about its realization, but when modeling a realization, it is necessary to indicate which specification it fulfils and what verification method that prescribes.

[0096] The realization layer comprises structural information on how the product elements are related. This includes all dimensions of relations, including abstraction, aggregation, and allocation. An abstraction realization bridges one of the two gaps in abstraction levels. The higher gap that is realized can describe what application component that is realizing what customer function. The lower gap that is realized can describe what software file that is realizing what atomic component. An aggregation realization can describe what component that is realizing what placeholder of a composed component. This may include what external interfaces of the component that is realizing what delegation connector. An allocation realization can describe what platform component that provides resources to what application component (or in other word to what platform component an application component is allocated).

[0097] In the example of Figure 3, the layered hierarchical structure 300 comprises an argument fragment layer 350. The argument fragment layer contains all information related to the safety argumentation for the product elements. This includes detailing different types of claims and their related evidence. The information in the argument fragment layer 350 comprises all information needed, in addition to the information available in the underlying layers 310, 320, 330, 350, to model the safety arguments connecting all underlying information into a safety case. The information in argument fragment layer comprises safety case fragments with the related claims and evidence. These are, among other things, referencing the contract layer. A certain claim can be that a certain part of a contract is fulfilled. According to the contract model, a contract specifies what constraints are to be guaranteed by a certain product element, given that some other constraints can be assumed valued. This means that guarantee and assume, respectively, are role names for constraints applied.

[0098] The argument fragment layer models how a particular decoupled update brings the necessary structured arguments for building a valid safety case. Once again, there is a one- direction dependency as we can model a certain update without knowing about its safety argumentation pieces, but the modeling of the safety argument fragments must point out the related product elements for this argumentation.

[0099] The argument fragment layer contains the claims and the evidence. These are, among other things, referencing the contract layer. A certain claim can be that a certain part of a contract is fulfilled. According to the contract model, a contract specifies what constraints are to be guaranteed by a certain product element, given that some other constraints can be assumed valued. This means that guarantee and assume, respectively, are role names for constraints applied.

[0100] The argument fragment layer is based on the component structure in the component layer, the contract layer and the verification layer, and what is realized by the realization layer. Note that the component structure and the realization are related, such that what is realized also includes their specifications as formalized in the component structure. The argument model is also modular, well suited for the CI / CD framework, which implies among other things that every component, realization, and partial integration, brings a safety case fragment.

[0101] In the example of Figure 3, the layered hierarchical structure comprises a safety case layer 360. The information in the safety case layer comprises the structural information detailing how the information available in the underlying layers 310, 320, 330, 350, 360 form a full safety case for the safety-critical product 110, 110'.

[0102] The safety case layer 360 comprises the structural information detailing how the information available in the underlying layers 310, 320, 330, 350, 360 form a full safety case for the safety-critical product 110, 110'. The safety case layer expresses the full safety case 130, encompassing how all argument elements of all the safety fragments relate in a complete structured argument for the entire safety-critical product 110, 110' or customer functionality thereof.

[0103] The safety case layer is about the language bringing the entire safety case together. This is what is automized in the Cl pipeline. As for the other layer relations, there is a one-way dependency with the fragments and other information about the product not referencing explicitly how they are used in the full safety case, but the building of the complete safety case is referencing the used fragments and other information related to the product.

[0104] Figure 6A schematically illustrates, in terms of a number of functional units, the components of a processing unit 600 according to embodiments of the discussions herein. Processing circuitry 610 is provided using any combination of one or more of a suitable central processing unit CPU, multiprocessor, microcontroller, digital signal processor DSP, etc., capable of executing software instructions stored in a computer program product, e.g., in the form of a storage medium 630. The processing circuitry 610 may further be provided as at least one application specific integrated circuit ASIC, or field programmable gate array FPGA. Particularly, the processing circuitry 610 is configured to cause the processing unit 600 to perform a set of operations, or steps, such as the methods discussed in connection to Figures 4-5 and generally herein. For example, the storage medium 630 may store the set of operations, and the processing circuitry 610 may be configured to retrieve the set of operations from the storage medium 630 to cause the processing unit 600 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 610 is thereby arranged to execute methods as herein disclosed.

[0105] The storage medium 630 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The control unit 600 may further comprise an interface 620 for communications with at least one external device. As such the interface 620 may comprise one or more transmitters and receivers, comprising analogue and digital components and a suitable number of ports for wireline or wireless communication. Figure 6B illustrates a computer readable medium 660 carrying a computer program comprising program code means 670 for performing the methods detailed in Figures 4-5 and the techniques discussed herein, when said program product is run on a computer. The computer readable medium and the code means may together form a computer program product 650.

Claims

CLAIMS1. A computer-implemented continuous integration tool (102) for generating a safety case (130, 130') for a safety-critical product (110, 110'), wherein the safety-critical product comprises a plurality of product elements (111A, 111B, 111N), at least a portion of the product elements comprises information expressed using a formalized description language, and said information includes one or more safety case fragments, wherein the continuous integration tool is configured to: receive an updated safety-critical product (110'), where the updated safety-critical product (110') comprises an update (120) introduced to the safety-critical product (110), and wherein the update (120) comprises an addition, an alteration and / or a removal of one or more product elements, verify consistency and completeness of the updated safety-critical product (110') by validating the information in the product elements, including the update (120), and their associated safety case fragments by using the formalized description language to automatically parse the relations between product elements as well as the contents of the product elements, and generate the safety case (130') for the updated safety-critical product (110') based on the information in the product elements, including the update (120), and all associated safety case fragments.

2. The continuous integration tool (102) of claim 1, further configured to: receive new evidence (240) referenced in the safety case (130') for the updated safety- critical product (110'), validate all referenced evidence by confirming that the referenced evidence supports the argument which links the evidence to the claim, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion, andpublish the safety case (130') and the evidence chain (250).

3. The continuous integration tool (102) of claim 2, further configured to: promote the updated safety-critical product (110') to a deployment candidate in a version control system or any other type of release management platform.

4. The continuous integration tool (102) of any of claims 1-3, wherein the information expressed using the formalized description language is defined according to a layered hierarchical structure (300), in which the information comprise a plurality of layers arranged in hierarchical order such that information in any single layer can only reference its own information and the information in its underlying layers.

5. The continuous integration tool (102) of claim 4, wherein the layered hierarchical structure (300) comprises a component layer (310), and wherein the information in the component layer (310) comprises functional and structural information for modeling product elements that comprise system components and their constituent parts such that these elements are possible to individually specify and update independently of their position in a system architecture.

6. The continuous integration tool (102) of any of claims 4-5, wherein the layered hierarchical structure (300) comprises a contract layer (320), and wherein the information in the contract layer (320) comprises all information needed, including contracts, in addition to the information available in the underlying layers (310), to model safety constraints applicable to the product elements (111A, 111B, 111N).

7. The continuous integration tool (102) of any of claims 4-6, wherein the layered hierarchical structure (300) comprises a verification layer (330), and wherein the information in the verification layer (330) comprises all information needed, in addition to the information in the underlying layers (310, 320), to model verification criteria for the contracts.

8. The continuous integration tool (102) of any of claims 4-7, wherein the layered hierarchical structure (300) comprises a realization layer (340), and wherein the information in the realization layer (330) comprises all information needed, in addition to the information available in the underlying layers (310, 320, 330), to model the realization of thecomponents and their integration with each other, with respect to the contracts and the verification criteria for the contracts.

9. The continuous integration tool (102) of any of claims 4-8, wherein the layered hierarchical structure (300) comprises an argument fragment layer (350), and wherein the information in the argument fragment layer (350) comprises all information needed, in addition to the information available in the underlying layers (310, 320, 330, 350), to model the safety arguments connecting all underlying information into a safety case.

10. The continuous integration tool (102) of any of claims 4-9, wherein the layered hierarchical structure (300) comprises a safety case layer, and wherein the information in the safety case layer comprises the structural information detailing how the information available in the underlying layers (310, 320, 330, 350, 360) form the safety case (130') for the safety-critical product (110, 110').

11. A computer-implemented method for generating a safety case (130, 130') for a safety- critical product (110, 110') in a continuous integration tool chain (100), wherein the safety- critical product (110, 110') comprises a plurality of product elements (111A, 111B, 111N), where at least a portion of the product elements comprises information expressed using a formalized description language, and where said information includes one or more safety case fragments, the method comprising: introducing (SI) an update (120) to the safety-critical product (110) to obtain an updated safety-critical product (110'), wherein the update (120) comprises an addition, an alteration and / or a removal of one or more product elements, verifying (S2) consistency and completeness of the updated safety-critical product (110'), wherein verifying comprises validating the information in the product elements (111A, 111B, 111N), including the update (120), and their associated safety case fragments by using the formalized description language to automatically parse the relations between product elements as well as the contents of the product elements, and generating (S3) the safety case (130') for the updated safety-critical product (110') based on the information in the product elements (111A, 111B, 111N), including the update (120), and all associated safety case fragments.

12. The method of claim 11, further comprising: receiving (S4) new evidence (240) referenced in the safety case for the updated safety- critical product (110'), validating (S5) all referenced evidence by confirming that the referenced evidence supports the argument which links the evidence to the claim, and in response to confirming, obtaining an evidence chain, wherein the evidence chain comprises the evidence as an artifact, information of the source of the evidence, information regarding the assertion of its applicability, and the source of that assertion, and publishing (S6) the safety case and the evidence chain (250).

13. The method of claim 12, further comprising: promoting (S7) the updated safety-critical product (110') to a deployment candidate in a version control system or any other type of release management platform.

14. The method of any of claims 11-13, wherein the information expressed using the formalized description language is defined according to a layered hierarchical structure (300), in which the information comprise a plurality of layers arranged in hierarchical order such that information in any single layer can only reference its own information and the information in its underlying layers.

15. The method of claim 14, wherein the layered hierarchical structure (300) comprises a component layer (310) , and wherein the information in the component layer (310) comprises functional and structural information for modeling product elements that comprise system components and their constituent parts such that these elements are possible to individually specify and update independently of their position in a system architecture.

16. The method of any of claims 14-15, wherein the layered hierarchical structure (300) comprises a contract layer (320), and wherein the information in the contract layer (320) comprises all information needed, including contracts, in addition to the information available in the underlying layers (310), to model safety constraints applicable to the product elements (111A, 111B, 111N).

17. The method of any of claims 14-16, wherein the layered hierarchical structure (300) comprises a verification layer (330), and wherein the information in the verification layer (330) comprises all information needed, in addition to the information in the underlying layers (310, 320), to model verification criteria for the contracts.

18. The method of any of claims 14-17, wherein the layered hierarchical structure (300) comprises a realization layer (340), and wherein the information in the realization layer (330) comprises all information needed, in addition to the information available in the underlying layers (310, 320, 330), to model the realization of the components and their integration with each other, with respect to the contracts and the verification criteria for the contracts.

19. The method of any of claims 14-18, wherein the layered hierarchical structure (300) comprises an argument fragment layer (350), and wherein the information in the argument fragment layer (350) comprises all information needed, in addition to the information available in the underlying layers (310, 320, 330, 350), to model the safety arguments connecting all underlying information into a safety case.

20. The method of any of claims 14-19, wherein the layered hierarchical structure (300) comprises a safety case layer (360), and wherein the information in the safety case layer (360) comprises the structural information detailing how the information available in the underlying layers (310, 320, 330, 350, 360) form the safety case (130') for the updated safety-critical product (110').

Images