1. Introduction

Safety-related and safety-critical electronic products have to be developed according to industry specific functional safety and cybersecurity standards. For the automotive industry, these standards are ISO 26262 and ISO 21434.

All functional safety and cybersecurity standards set requirements for

• the product development process and
• work products which prove that the product is reliable and no safety or cybersecurity goals can be violated during intended product use or foreseeable product misuse.

The number of requirements set by these standards is quite substantial. Not only is it difficult to keep them all in mind, it is also possible to interpret them in different ways. It is even more difficult to execute a product development project in a manner that is both fully standards-compliant AND efficient.

That is why

• AutoFusa Consultancy Services Pvt Limited from Bengaluru, India, and
• automated conformance GmbH from Nuremberg, Germany,

have agreed to collaborate so as to provide their customers with a comprehensive offering of training, consultancy and hands-on engineering services which help achieve process and product compliance to the relevant functional safety and cybersecurity standards. The two companies have each developed a particular software tool:

• the AutoPro tool, by AutoFuSa, for process compliance, and
• the autoConform® Software by automated conformance, for product compliance.

Section 2 describes how the AutoPro tool enables efficient process compliance. Analogously, Section 3 describes how the autoConform® Software enables efficient product compliance. Finally, Section 4 summarizes the advantages and customer benefits of the way product development is done with the help of these two software tools.

2. Process Compliance with the help of the AutoPro Tool

AutoPro represent the V-model-based process flow of product development according to ISO 26262. Fig. 1 shows this process flow for the „Concept Phase“ of ISO2626-3. Once the output documents (FSC and FSC verification report) are baselined, they are uploaded into the AutoPro tool‘s output section. In the tool, these output documents automatically appear wherever they are used as inputs. The status of each document is indicated by the respective color representation.

Fig. 1: ISO 26262 Concept Phase process and work products in the AutoPro tool.
© AutoFusa Consulting Services Pvt Limited

The AutoPro tool is server-based and installed at the customer’s site. The tool provides the possibility to connect external stakeholders through web interfaces with fully configurable access rights, compliant with ISO 27001:2022. This helps the product owner to manage other stakeholders effectively, as shown in Fig. 2.

Fig. 2: Connecting various stakeholders to the AutoPro tool.
© AutoFusa Consulting Services Pvt Limited

3. Work product Content Creation with the help of the autoConform® Software

The autoConform® Software enables the semi-automated creation of the content of all work products on the left side of the V-model plus the test case specifications on the right side of the V. The number of work products needed depends on the number of architectural levels of the product to be developed. Fig. 3 shows the V-model for a product with two system levels (referred to in the figure as „Product or System Level“ and „Subsystem Level“), one hardware level, and one software level.

Fig. 3: V-model for a product with 4 architectural levels, plus the product’s parent level.
© automated conformance GmbH

On the left side of the V,

• an architectural design specification (in the form of a Specification Document and an Interface Document),
• an architectural model,
• safety analyses (i.e., HARA at the top level; FTA, DFMEA and DFA at all other levels; FMEDA at E/E hardware level) and
• technical requirements

are needed at every architectural level. Fig. 4 lists all of these work products for a product with 4 architectural levels. As can be seen in the figure, the full set of work products comprises 48 documents. However, Fig. 4 also states that just 10 different document types suffice as templates for all of these work products. With the help of the autoConform® Software, the content of the work products is created „top-down“ semi-automatically, which is several times faster than doing it manually.

Fig. 4: Work products on the left side of the V-model for a product with 4 architectural levels.
© automated conformance GmbH

4. Advantages and Benefits

How do the AutoPro tool and the autoConform® Software allow their customers to achieve FuSa and Cybersec process and product compliance in a systematic and simple way?

The AutoPro tool provides an integrated process and documentation environment. The main benefits of the tool are that

• it guides the team through the workflow defined by the product architecture and the FuSa standard,
• it provides an up-to-date status of process compliance during project execution, and
• it reduces assessment and audit effort and duration.

The autoConform® Software allows for a semi-automated creation of the content all technical work products of the V-model, including bi-directional traceability between the work products. Detailed design specifications and test reports are not covered by the autoConform® Software. These work products are typically created with the help of CAD and testing tools.

Creating work products with the help of the autoConform® Software serves two purposes:

• quality: making the work products and the process of creating them compliant with the industry-specifc standard on functional safety (e.g. ISO 26262), and
• time: minimizing the time and effort it takes to create, review and finalize all work products.

Feature (i) minimizes product-related risks, whilst feature (ii) minimizes product development costs and time-to-market.

1. Introduction

Functional safety standards require the development of a safety-critical product to be done according to the V-model of system development. Fig. 1 shows this V-model in the form that underlies the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and software

This article is about how the content and the order of the work products (i.e. the documents) of the V-model can be defined in such a way that an iteration-free creation of all work products is possible.

An iteration-free V-model workflow has two decisive advantages.

1. A product design change or correction made in a specific V-model work product can only have an impact on subsequent work products in an iteration-free V-model. Using the (bi-directional) traces between the contents of interdependent work products, these impacts can be determined in full very quickly.
2. A product design change or correction made in a specific work product of the V-Model can only affect subsequent work products in an iteration-free V-Model. Based on the links ("traces") between the contents of interdependent work products, these effects can be fully determined very quickly.

In other words:

1. Product development according to an iteration-free V-model is significantly faster than product development according to a non-iteration-free V-model.
2. The "impact analysis" required by functional safety standards

• in case of a modification of a safety-critical product, or
• when a safety-critical product is intended to be used in a different context

is much easier to carry out if the work products documenting the product development follow an iteration-free V-model.

Section 2 describes the iteration-free V-model workflow. Section 3 summarizes the prerequisites for an iteration-free V-model workflow.

2. Iteration-free V-model workflow

The iteration-free V-model process is shown in Fig. 2.

Fig. 2: Iteration-free V-model workflow

 Fig. 2 shows the V-model process for a product whose product architecture consists of

• a system level,
• n subsystem levels (with the n-th subsystem level being the E/E hardware level), and
• 2 software levels.

Fig. 2 thus shows that there can basically be any number of system, hardware and software levels in a product architecture. At its simplest, the product architecture of an electronic product with embedded software contains only one E/E hardware level and two software levels (namely, the level of the entire software and one software detailed design level). All other system, hardware and software levels may exist, but don‘t have to exist.

In Fig. 2, the V-model workflow is indicated by green arrows. The workflow begins in the upper-left corner at the work products "Item Definition" and "External System Interface Specification". These two work products are closely related to each other and should be created together.

The same applies to the safety analyses "(A)SIL allocation", "FTA", "DFMEA" and "DFA" at each product architecture level and the safety requirements created from these analyses: these work products are also closely related to each other and should therefore be created together.

In Fig. 2, there are bidirectional arrows only between

• the design and interface specifications (far left) and
• the safety analyses (in the second block column from the left).

These bidirectional arrows indicate that,

• on the one hand, the safety analyses (in the second block column from the left) require information from the design and interface specifications (far left), and,
• on the other hand, information such as the "(Automotive) Safety Integrity Level - (A)SIL", is first determined by "Hazard Analysis and Risk Assessment" or "ASIL Allocation" and subsequently entered into the design and interface specifications.

It cannot be concluded from Fig. 2 that the iteration-free V-model workflow is uniquely defined. For instance, it is (theoretically) possible to first edit the leftmost block column (design and interface specifications) in Fig. 2 from top to bottom, subsequently the second block column from the left (safety analyses) from top to bottom, then the third block column (requirements) from top to bottom, and finally the fourth block column (test specifications).

However, the usual and most practical workflow is from left to right, level by level, starting at the top level.

3. Requirements for an iteration-free V-model

An iteration-free V-model can be applied whenever all requirement, design, and test specifications can be related to a hierarchical product architecture in which all physical hardware and software elements and their respective functions have been defined by top-down decomposition.

In addition, the expected content of each V-model work product must be defined such that it presupposes only content contained or defined in one of the upstream work products.

The work product templates of the autoConform® methodology and software are designed to meet both of these requirements. Making the V-model workflow iteration-free is key for speeding up the product development process significantly.

1. Introduction

In order to achieve the desired quality and safety of an electronic product, the quality and safety-relevant functions and properties of the product and its components must be determined and optimized during product development and achieved and maintained during product production. The identification and optimization of these product functions and properties is carried out during product development by:

• defining product functions with measurable performance,
• performing safety analyses of the product design, where these safety analyses always include a Design Failure Modes and Effects Analysis (DFMEA),
• carrying out simulations basedd on physical and data-driven product models, and
• producing and testing hardware prototypes of the product.

Knowing the critical product functions and properties, the identification, optimization and control of production process parameters which influence the critical product properties is achieved by:

• a process safety analysis of the production process (PFMEA),
• AI prediction models for the process parameters, including the specification of setpoints.
• AI predictive models for process parameters including the interpretation of setpoints and specifications.

The quality assurance measures in production are described as a sequence of control steps in the production control plan. The description of each control step includes the methodology used, the equipment and tools applied, as well as the quality and acceptance criteria.

Section 2 describes how quality and safety-related product properties are advantageously identified and optimized in the product development phase. Section 3 shows how product properties and process parameters can be efficiently monitored, optimized and controlled in the production environment. Section 4 outlines the form in which

• automated conformance GmbH and
• Contech Software & Engineering GmbH

provide the described methodologies to their customers.

2. How can quality- and safety-relevant product properties and production process parameters be identified and optimized?

As an example of an application, let's consider the powertrain inverter of an electric vehicle – an automotive safety-critical system whose probability of failure due to hardware faults must be very low. Powertrain failures considered include failures of

• Inverter components,
• detachable connectors and
• fixed joints such as laser welded joints.

As an example, let's take a closer look at the laser welded connections of the busbars in the power section of the inverter. Apart from the operating conditions, the failure rate of these laser welded joints depends largely on selected properties of the laser welded joint, such as the welding depth and geometry. These properties are in turn influenced by about 40 parameters of the laser welding process. A combination of a DFMEA and an analysis of product sample measurements shows that the laser welding process parameters "gap dimension in z-axis", "local heat dissipation during the welding process", "power and reflected power", "weld direction" and "weld transverse offset" are the most important ones due to their variability (and thus high "risk number"). On the basis of statistical experimental design models, measurements are carried out on product samples and optimal values of the production parameters are determined by an engineering AI. These optimal parameter values are then used and validated in the production of further product samples.

Fig. 1 shows the entire process which consists of eight steps.

Fig. 1: Eight-step procedure for the identification and optimization of quality- and safety-relevant product properties and production process parameters. © Contech Software & Engineering GmbH, https://www.contech-analyser.de/

3. How to monitor and optimize the parameters of the production process?

During the set-up of the serial production process, the monitoring, control and regulation of the critical production parameters is implemented to ensure the quality and functional safety of the product to be manufactured.

Fig. 2 shows the structure and process of online monitoring and control of production process parameters. It shows how machine data are read out via one or several industrial standard communication interfaces such as OPC UA, Ethernet/IP, Modbus, Profinet, etc., are transferred to a database, and are analyzed in real time by the engineering AI system Analyser® from Contech Software & Engineering. The Analyser® software predicts the production quality and provides the shop floor worker with various kinds of information, such as recommendations for actions, so as to maintain the desired production quality. An online connection of the engineering AI system Analyser® to selected machines can also be implemented, which automatically readjusts critical machine parameters – without any need for intervention by machine operators or workers, see Fig. 2.

Fig. 2: Online monitoring and control of production process parameters. © Contech & Engineering GmbH, https://www.contech-analyser.de/

Based on occasional test measurements during prodution, the engineering AI Analyser® tells the industrialization engineer

• whether the prediction model is still valid or has to be re-trained;
• whether there could be errors in the measurement equipment so that the production quality and the factors influencing the production quality are no longer predicted correctly, and
• whether checks and possibly also re-calibrations of the measurement equipment are due.

4. Methodology and offer to customers

For the product development and product manufacturing steps described in the previous sections, the companies automated conformance GmbH and Contech Software & Engineering GmbH offer suitable methods, engineering services and software.

automated conformance GmbH have developed the autoConform® methodology and software. Based on this methodology and software, the company offers engineering services for a standard-compliant and fast implementation of all development phases of a safety-critical product. The autoConform® methodology and software enable, for instance the semi-automated creation of technical design, requirements and test specifications; automated visualization and checking of system, hardware and software architectures as well as semi-automated safety and reliability analyses.

Contech Software & Engineering GmbH is an engineering company with its own patented engineering AI system, which ensures robust products and stable industrial processes on the basis of small samples. Contech robustifies a given product design on the basis of physical and data-driven simulations, prototype tests and AI prediction models of the product functionalities, including their setpoints and tolerances. In the industrialization phase, this robust design methodology and engineering AI are used to determine all process parameters with target values and permitted tolerances so as to control product quality consistently in real time during series production. In this way, risks identified in design and process FMEAs are reduced significantly.

Together, the two companies offer a comprehensive range of methods, engineering services and software for efficient and high-quality product development and manufacturing. The combined offering of the two companies enables

• rapid time-to-market of a new or modified product
• with minimal technical risks,
• reduced consumption of energy, materials and resources
• at a lower cost.

1. Introduction

Functional safety standards require the development of a safety-critical product to be done according to the V-model of system development. Fig. 1 shows this V-model in the form that underlies the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and software

Parameters are typically included in all documents of the V-model, on the left and right sides of the V, and on all product architecture levels. Parameters are not limited to software parameters in the form of either software configuration data or software calibration data. Configuration and calibration parameters are also present at the system and hardware levels.

The correct handling of all system, hardware and software parameters is a prerequisite for the correct management of product variants.

Section 2 makes a proposal as to how parameters can be handled advantageously in the V-model documents. Section 3 explains the benefits of this proposal.

2. Handling of parameters in the V-Modell documents

The proposal for handling parameters in the V-Model documents consists of four sub-proposals, subsequently referred to as (A), (B), (C) and (D).

(A) It is proposed that all parameters be specified in a central parameter document. Instead of one parameter document, two parameter documents can be created, one for system and hardware parameters and the other for software parameters.

Such parameter documents are identical in structure to interface documents in which generalized signals are specified: Parameter and interface documents each consist of only one document sheet which contains all parameter or signal attributes. The attributes which characterize a parameter are nearly the same as the attributes which characterize a signal.

(B) It is proposed that all parameter names be chosen in such a way that it is obvious from the name that it is a parameter name. One way to accomplish this is to let each parameter name start with a string that is used exclusively in parameter names.

Examples:

• “PARAM_” or
• “PAR_” or
• “P__”.

(C) All attribute values (such as the default value of a parameter) are specified in the central parameter document according to (A). To make the rest of the documents in which a specific parameter occurs more readable, it is proposed that the default value of the parameter is specified in parentheses after the parameter name.

Example:

PAR_Spring1Stiffness_Npm(4.7N/m)

Note: If the parameter name already contains the unit of the parameter value, then the unit information does not have to be repeated in parentheses after the parameter name.

If further parameter attribute values are required for the readability of a text passage, it is suggested to extend the information provided in parentheses after the parameter name such that all required parameter attribute names followed by the corresponding parameter attribute value are listed in the parentheses after the parameter name: (Parameterattribut_#1 name: Parameterattribut_#1 value, Parameterattribut_#2 name: Parameterattribut_#2 value, ...).

Example:

PAR_Spring1Stiffness_Npm(DEFAULT: 4.7N/m, MINIMUM: 4.4N/m, MAXIMUM: 5.0N/m).

(D) Finally, it is proposed that every numerical value which is referred to in more than one V-model document does not appear as "naked" number, but as a parameter in every V-model document.

Example: Instead of entering "500ms" as the Fault Tolerant Time Interval (FTTI) for the safety goal #1 (SG1) in the HARA and other documents, "PAR_FTTI_SG1_ms(500ms)" or "PAR_FTTI_SG1_ms(500)" is entered instead.

3. Benefits of the Parameter Handling Proposal

Proposal (A), the specification of each parameter in a central parameter document, ensures that the parameter names are unique and consistent across all V-model documents.

Suggestions (B), (C) and (D) ensure that all numerical values that occur repeatedly in the V-model documents can be updated automatically, which in turn is a practical prerequisite for keeping all parameter values consistent and correct.

1. Introduction

Functional safety standards require the development of a safety-critical product to be done according to the V-model of system development. Fig. 1 shows this V-model in the form that underlies the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and software

In the V-model of Fig. 1, a single box usually does not stand for one work product, but for several work products. Section 2 elaborates on these work products. Section 3 explains why it makes sense to create all of these work products and how it can be done in a time-saving way.

2. Work Products on the Left Side of the V-Model

Fig. 2 shows how the left side of the V-model of Fig. 1 is „translated“ into specific work products.

Fig. 2: Translation of the left side of the V-model into specific work products

The starting point of the V-model is the design specification (1) at the top level, the „Product's Parent Level". This design specification is subdivided into two documents:

1a) the specification document "Item Definition", which describes the environment, interfaces, functions and static properties of the product to be developed, and

1b) the interface document "External System Interface Specification", which specifies all intended and unintended interactions of the product with its environment and with other external systems in the form of mechanical, electrical, communication, etc. intended signals, as well as unintentional but unavoidable disturbance signals.

The safety analyses (2) at the top level correspond to the Hazard Analysis and Risk Assessment (HARA, 2a) of the product and the safety requirements derived from it (2b). The main results of the HARA (2a) are

• the safety goals of the product to be developed, and
• the Safety Integrity Level (SIL) of each safety goal and thus also of each product output.

The highest safety integrity level assigned to one or more of the product outputs in the HARA equals the safety integrity level of the entire product. All safety integrity levels determined by the HARA are entered in the previously created work products "Item Definition" (1a) and "External System Interface Specification" (1b).

The product safety requirements, which are derived from the HARA in conjunction with the "Item Definition" and the "External System Interface Specification", form the Functional Safety Concept (FSC, 2b) of the product.

The FSC, if included in the system requirements (3), usually only represents a small part of (3). The majority of the system requirements (3) are derived directly from the "Item Definition" (1a), the "External System Interface Specification" (1b) and higher-level product requirements.

At the next level, the product or system level, the first thing to do is to create the design specification (4). This design specification (4) is subdivided into

4a) the specification document "System Architectural Design Specification", which specifies

• the system,
• the system states and modes of operation, and
• the system elements with their
  • Interfaces
  • Functions
  • system state-dependent function activations and
  • static properties.

and

4b) the interface document "Internal System Interface Specification", which specifies all intended and unintended interactions between the system elements inside the system or product.

The safety analyses (5) include

5a) the following analyses of the product architecture and design:

• SIL allocation (in automotive engineering: ASIL allocation),
• Fault Tree Analysis (FTA),
• Design Failure Mode and Effects Analysis (DFMEA) and
• Dependent Failure Analysis (DFA),

and

5b) Requirements for the system elements resulting from the safety analyses “SIL allocation”, “DFMEA” and “DFA” in (5a).

The SIL allocation in (5a) determines the safety integrity level of the outputs and inputs of each system element, and thus also the safety integrity level of each individual system element. Analogous to the level above, the safety integrity levels determined by the SIL allocation are entered into the previously created work products "System Architectural Design Specification" (4a) and "Internal System Interface Specification" (4b) at the system level. However, we still recommend to create the document "SIL Allocation at System Level" as a standalone work product and include it in the bi-directionally traced work product list which forms the basis for the safety case.

The purpose of the FTA in (5a) is to determine the single-point and multiple-point faults that can lead to the violation of a safety goal. The single-point faults identified in the FTA (specifically by the analysis part "Cut Set Analysis") are subsequently dealt with in a DFMEA. In such a DFMEA, the needed single-point fault prevention and mitigation measures are defined, and the associated requirements are formulated. Analogous to the treatment of single-point faults in a DFMEA, the multiple-point faults, especially the dual-point faults identified in the FTA are analyzed in a DFA, and technical safety requirements for the mitigation and prevention of multiple-point faults are formulated within the framework of the DFA.  

The requirements (5b) are referred to as 'technical safety requirements'. They are typically included in the technical requirements (6) for the system elements, but usually form only a fraction of the requirements (6). The majority of the requirements (6) are derived directly from the work products (4a) and (4b) as well as the higher-level requirements (3).

At the product architecture levels below the system level, the structure of the work products just described for the system level is repeated. At the electric/electronic (E/E) hardware level, an FMEDA ("Failure Modes, Effects and Diagnostic Analysis") has to be added to the safety analyses. The FMEDA provides quantitative estimates of the reliability of the E/E design.

When analyzing the software architecture and design,

• the deductive analysis method “FTA” and
• the inductive analysis method “DFMEA”

can be combined to a single analysis method, the SHARD ("Software Hazard Analysis and Resolution in Design").

Matching Fig. 1 and Fig. 2, Table 1 lists each individual work product on the left side of the V-model.

Table 1: List of essential work products on the left side of the V-model

3. Work Product Creation

The total number of work products depends on the number of product architecture levels. Table 1 lists the work products for a product with the architecture levels

• system level,
• subsystem level,
• E/E hardware level,
• (entire) software level and
• software detailed design level.

If the product consists of just a printed circuit board in a housing, then both the system level and the subsystem level (and the work products associated with these two levels) do not exist. On the other hand, it is possible for a product to have a subsubsystem level in addition to the system and subsystem levels. The software architecture can also be subdivided into more than one software detailed design level. The conclusion from these observation is that unnecessary analysis and documentation effort can be avoided by defining the absolutely necessary product architecture levels only.

In view of the high number of work products in Table 1, the obvious question is whether the number of work products can be reduced. With a given product architecture and a given number of product architecture levels, it is unfortunately not possible to simply omit individual work products, because otherwise either

• the full traceability of technical requirements and design decisions would would be lost, or
• some of the safety analyses, which are required by functional safety standards, may not be done.

Fortunately, the autoConform® software is a tool that provides suitable templates for all work products and fills large parts of them automatically. With the autoConform® software, it is possible to create all work products in a complete, consistent, correctly and, not least to mention, in a very time-saving manner.

1. Introduction

Functional safety standards require that a safety-critical product is developed according to the V-model of system development. Fig. 1 shows how the V-model is implemented by the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and autoConform® software

As can be seen in Fig. 1, safety analyses are foreseen at every product architecture level. These safety analyses comprise

• a Preliminary Hazard Analysis (PHA) or a Hazard Analysis and Risk Assessement (HARA) at the product or system level; and
• a combination of a deductive analysis (Fault Tree Analysis, FTA), an inductive analysis (Failure Modes and Effects Analysis, FMEA) and a Dependent Failure Analysis (DFA) at all other product architecture levels.

Cybersecurity analyses of the system typically have to be conducted in addition to safety analyses.

Furthermore, it is recommended to perform complexity analyses of the product’s architectural design as unnecessary complexity reduces product quality, especially reliability, and increases product development, manufacturing and maintenance/service costs.

All of these analyses have some prerequisites in common which are described in Section 2. Section 3 summarizes the main insights of this article.

2. Prerequisites for System Analyses

The first prerequisite is derived from the fact that all system analyses are based on the static product architectural design. Therefore, the product architectural design must be suitably documented, and the documented product architectural design must be complete from the top level down to the product architecture level to be analyzed. If one or more product elements are missing in the product architectural design, or if the product architectural design contains „loose ends“ in the form of open or disconnected interfaces and signals, then the analysis performed on this basis may be misleading. This is because the „loose ends“ may result in important failure propagation or intrusion paths being overlooked, or in a grossly underestimated system complexity.

Prerequisite #1: Prior to performing an analysis at a particular product architecture level, the static product architectural design must be complete from the top product architecture level down to the product architecture level to be analyzed.

The second prerequisite is derived from the fact that all of the analyses mentioned in the introduction have to be conducted top-down. For instances, there is little point in performing safety analyses at the subsystem level if no safety analysis has been done at the product or system level. This is because we first need to know which safety goals and safety requirements the entire product needs to satisfy, before we can break down these product safety requirements into safety requirements for the product elements.

Prerequisite #2: An analysis at a particular product architecture level should only be conducted after having completed the corresponding analyses at all higher product architecture levels.

Some analyses not only depend on the static product architectural design, but can become much easier if other analyses had been done before. For instance, safety and cybersecurity analyses generally get more and more elaborate the more complex the system is. So investigating system complexity and reducing system complexity as much as possible should always be done before conducting safety and cybersecurity analyses. Another example is the order in which safety analyses are conducted at a particular product architecture level. An FTA reveals both the single-point failures and the multiple-point failures. The analysis and treatment of single-point failures is typically done by an FMEA, and the analysis and treatment of multiple-point failures by a DFA. Therefore, it makes sense to perform the safety analyses at a particular product architecture level in the order FTA first, FMEA second, DFA third.

Prerequisite #3: If a particular analysis would benefit from the results of other analyses, those other analysis should be done first.

The recommended order of system analyses is this.

a) At the product or system level:

1. Complexity analysis,
2. PHA/HARA,
3. Cybersecurity analysis.

b) At all other product architecture levels:

1. Complexity analysis,
2. FTA,
3. FMEA (or another inductive method like an FMEDA),
4. DFA,
5. Cybersecurity analysis.

3. Summary

All system analyses are based on the static product architectural design which must be complete, i.e., free of missing elements or unconnected interfaces and signals.

All system analyses must be performed top-down, starting at the top product architecture level which is the product or system level.

The system analyses are recommended to be conducted in a particular order:

1. Complexity analysis,
2. Deductive analysis (typically a Fault Tree Analysis (FTA)),
3. Inductive analysis (typically a Failure Modes and Effects Analysis (FMEA)),
4. Dependent Failure Analysis (DFA), and
5. Cybersecurity analysis.

1. Introduction

Virtually all functional safety standards require that a safety-critical product is developed according to the V-model of system development. Fig. 1 shows how the V-model is implemented by the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and software

In this V-model, on the left side of the V,

1. a design specification,
2. one or more security analyses as well as
3. a requirements specification

are created in that order at every product hierarchy level, starting from the top. On the right side of the V, verification and validation specifications, plus the associated test reports, form the „counterparts“ of the requirement specifications on the left.

Within a product architecture level, the technical requirements in the requirements specification are generated semi-automatically from the design specification and the safety analyses. The traceability of each individual generated requirement to the sources in the design specification and in the safety analyses of the same product architecture level is ensured because the autoConform® software creates these links automatically.

Similarly, the traceability of all verification and validation test specifications to the associated technical requirements is given, because the test specifications are derived from the requirements semi-automatically, and the links between requirements and test specifications are created automatically in this process.

What remains to be clarified is how the traceability of design decisions and requirements between neighbouring product architecture levels can be established automatically. Section 2 describes the linking of design decisions and Section 3 does the same for technical requirements. Section 4 summarizes the essential prerequisites for automated traceability of requirements, design decisions and tests.

2. Automated Linking of Design Decisions of Different Product Architecture Levels

Each specification document describes a "parent" and the parent‘s "child elements".

The links between the entries of hierarchically adjacent specification documents can be automated because

1. the specification documents are structured in the same way at every product architecture level,
2. a "parent" in the specification document of a particular product architecture level had already been introduced as a "child element" in the specification document one product architecture level above, and
3. the link between "parent" and "child element" (as well as between "parent functions" and "child element functions") is described in each specification document.

If the specification documents of all product architecture levels have been created with the help of the autoConform® software and the information just described is contained in the specification documents, then the autoConform® software can automatically link design decisions, i.e. the autoConform® software can link entries in the specification documents of adjacent product architecture levels.

3. Automated Linking of Technical Requirements of Different Product Architecture Levels

The automatic linking of the technical requirements of adjacent product architecture levels exploits the fact that

a) the autoConform® software generates the technical requirements from the specification document of the respective product architecture level in the same way at every product architecture level,

b) the names introduced in the specification document for parent and child elements as well as their functions, interfaces and signals are „re-used“ without any modifications in the technical requirements

and furthermore

c) the specification documents of adjacent product architecture levels are linked to each other (see Section 2 above).

Under these conditions, the autoConform® software can automatically link technical requirements, i.e. the autoConform® software can link entries in the requirements documents of adjacent product architecture levels.

1. Introduction

Structural complexity, or more precisely: low structural complexity, is a quality characteristic of a system or software design. If the system or software design is structurally complex, then it is

• more time-consuming and therefore more expensive to develop,
• technically more difficult and therefore more costly to manufacture and maintain,
• more error-prone and therefore less reliable and
• harder to understand and therefore less convincing in terms of its safety argument.

So, controlling (preferrably: minimizing) structural complexity in the system and software design process is of utmost importance. Suppose we have two possible system or software architecture designs: how can we decide which design is better because its structural complexity is lower?

How can the structural complexity of a system or software be quantified?

A system architecture (and analogously a software architecture) is characterized by several aspects, namely

1. the decomposition of the system into its physical system elements,
2. the decomposition of system functions into system element functions,
3. the physical and functional interfaces and their interdependencies within the system and its elements, and
4. the generalized signals (i.e. the transfer of information, material or energy) and their interdependencies within the system and its elements.

We seek a structural complexity measure by means of which

1. the dependencies of the physical system elements,
2. the dependencies of the system element functions,
3. the dependencies of the system-internal interfaces, and
4. the dependencies of the system-internal (generalized) signals

can be evaluated.

Moreover, we want to take into account an important feature of safety-critical systems: the higher the required safety integrity level of a system part, the less structurally complex that system part is allowed to be.

Section 2 describes how we propose to measure and reduce structural complexity. Section 3 summarizes the main ideas of this article.

2. What is the most appropriate measure of structural complexity?

2.1. Structural Complexity of What?

The content of this Section 2.1 and the following Section 2.2 is largely based on [1].

As had already been mentioned in the introduction, structural complexity is about system- or software-internal dependencies: the more dependencies there are, the higher the structural complexity. Fig. 1 shows an example of a dependency tree and the associated adjacency matrix A (also known in the English literature as the “Dependency Structure Matrix”, or “DSM” for short).

Fig. 1: Dependency tree (left) and associated DSM (right), taken from [1], p. 34.

Note that

1. the dependencies of the physical system elements,
2. the dependencies of the system element functions,
3. the dependencies of the system-internal interfaces, and
4. the dependencies of the system-internal (generalized) signals

can all be represented by dependency trees and DSMs.

2.2. Recommended Structural Complexity Measure

Affecting or being affected by other system elements need not be direct – it may occur through intermediate connections. To capture this, we propose a structural complexity measure that takes into account both direct and indirect connections in the system architecture.

In safety-critical systems, one cannot assume that all system elements have the same safety integrity. To take this fact into account, we weight the system elements according to their safety integrity. The corresponding weighting matrix is given by

As for the structural complexity measure c we propose to calculate it as the Frobenius norm of the column-weighted extended reachability matrix R^ext where the columns are weighted according to the safety integrity of the system elements:

Which values should be chosen for the scalar weights?

In Tables 1 and 2 below we provide recommendations depending on whether

1. the “Safety Integrity Levels (SILs)” of IEC 61508 or
2. the “Automotive Safety Integrity Levels (ASILs)” of ISO 26262

are used to classify the system elements.

Table 1: Recommended weighting of system elements with SIL classification

Table 2: Recommended weighting of system elements with ASIL classification

ISO 26262:2018, Part 9, allows for a so-called "ASIL decomposition" of safety requirements. In practice, this idea is extended to ASIL decompositions of system elements and system functions that meet the decomposed safety requirements. The weights in Table 2 were chosen such that any kind of ASIL decomposition is "complexity-neutral". An example of such an ASIL decomposition is shown in Fig. 2 a) and b). Note that the structural complexity in a) and b) is the same.

Fig. 2: Dependency trees (a) without and (b) with ASIL decomposition.

2.3 Structural Complexity Reduction

Assume we have a candidate of the static system architecture. For this candidate system architecture we determine its c-value. Reducing the structural complexity of the system design means looking for alternative architectural designs with lower c-values (by “trial and error”).

Low c-values are typically attained by

• defining dependencies which „branch out“ top-down, but do not „re-connect“ further down,
• introducing SIL/ASIL decompositions and associated safety mechanisms as close to the safety-critical system outputs as possible, and
• ensuring that as much of the system functionality as possible is not safety-related or safety-critical.

3. Summary

In this article, a structural complexity measure c was taken from network theory and adapted to safety-critical systems. This measure c for structural complexity is based on a column-weighted extended reachability matrix. Such a reachability matrix can be determined for

1. the physical system and its decomposition into physical system elements,
2. the system and its functional decomposition,
3. the interface chains that end in the safety-related output interfaces of the system, and
4. the (generalized) signal chains that end in the safety-related outputs of the system.

The following properties expected of a structural complexity measure are met by c:

1. c is a measure in the mathematical sense (cf. e.g. [2]). In particular, for a system comprising the n elements s₁, …, s_n , the value of c is independent of the order of the system elements s₁, …, s_n.
2. The value of c increases with the number n of system elements.
3. The value of c increases with the number of direct or indirect dependencies between the system elements.
4. The value of c increases with increasing Safety Integrity Level of the system elements.

References

[1] Sturtevant, DJ: “System design and the cost of architectural complexity”, 2013, https://dspace.mit.edu/handle/1721.1/79551

[2] Measure (mathematics) – Wikipedia

1. Introduction

Delays in product development projects are often due to a lack of competencies, unclear requirements or immature technologies. These risks must be identified and addressed early if the product development project is to be completed successfully and efficiently.

2. Risk minimization strategies

1. Ensure that all necessary competencies are available

A development project can only be carried out in compliance with standards with a competent team. In addition to competence management, responsibilities as well as customer-supplier relationships within the project should be defined clearly to ensure smooth processes.

2. Formulate the full set of technical requirements

The first step is to create a complete design specification for the top product architecture level. This design specification forms the basis for the second step, the creation of the safety analysis at this level. The third step is to derive a complete set of technical requirements for this level. These three steps are repeated at the next lower product architecture level and so on until all product architecture levels are done.

3. Only use sufficiently mature technologies

Technologies that have not yet been used in a similar product should first be applied and tested in a research or pre-development project. Their integration into a product development project only makes sense once a sufficient level of maturity has been reached.

3. Summary

Minimizing product development risks requires:

• a competent team,
• precise and complete requirements,
• the use of mature technologies.

A structured approach reduces risks and ensures the success of development projects.

1. Introduction

Being able to assess the market readiness of a product under development is essential for making the progress of a development project transparent.

This contribution explains how the market readiness can be assessed by looking at the technical requirements and the available verification evidence. In this way, the remaining effort until full market readiness is achieved can also be estimated.

2. Determining reached maturity and remaining effort

1. Prerequisites

The market readiness of a product will only be assessible with sufficient accuracy if:

• all product safety analyses are completed,
• all requirements for the product and its elements – including requirements for production, operation, service and decommissioning – are formulated, and
• a clear integration and test strategy is available.

2. Linking requirements and test reports

A bidirectional link between requirements and test reports makes it possible to understand:

• which requirements have been successfully tested and are, therefore, have been correctly implemented and
• the implementation of which requirements is still open or in progress.

3. Visualize remaining effort

Burndown charts offer an effective method of visualizing progress. They show the proportion of requirements that have been successfully implemented and tested in relation to all requirements. The amount of work that has already been done can be used to estimate the amount of work that is still required.

3. Summary

The transparent assessment of market readiness is made possible on the basis of:

• completed product safety analyses,
• the complete set of technical requirements and associated test specifications,
• burndown charts visualizing the implemented requirements and the associated expenditure in relation to the requirements yet to be done.

This method allows projects to be managed effectively and market readiness to be demonstrated in a comprehensible manner at any time.