Typically, you should start with understanding the system or function that you want to create. This system or function is referred to by the term "item" in ISO 26262 and in medini analyze. You can imagine an item to be a function, system or sub-system, in short the "thing" that you want to investigate for its safety criticality - so the item is the root element for your safety analysis. The item definition can be performed with medini analyze in order to collect all the information needed for further analysis in the safety life-cycle. The safety life-cycle starts with the definition of the item which will be developed. The description shall support the comprehension of the item as well as help to perform the required analysis and developments activities defined in the safety life-cycle. [ISO Part 3 clause 5].

Try to identify those information in terms of sketches, draft specifications and architectural concepts that are relevant for the item. Such documents also include e.g. legal safety regulations, documentations of accidents with items of similar kind or sketches of the system. Any of the additional documents that describe the item should be added to the package by using the "Add external document" function available. Traces should be established between the item definition (or elements of the item definition) and those external documents.

Moreover, specify the function or the hierarchy of functions which will be performed by the item.

After the item has been understood, you should define a rough architecture for the item. The item architecture should contain the system parts or components which are involved in a realization of the item, and potentially also those components which are relevant in terms of being the environment for the item. You need to specify which of those components of the item architecture are part of the item and which are not.

There might be several different item architectures possible, i.e. you can realize the same item with different approaches. If that is the case, try to identify those components which are common in the different approaches and define the specifics of each architectural approach as a specialization (or variant) of the common architecture.

Finally, the mapping of the item's functions onto the elements of the items architecture has to be done. Define traces from a function to all architecture elements which are involved in the execution of that function.

The next step in the concept phase is the hazard analysis and risk assessment. The hazard analysis and risk assessment for a specified item aims at the identification and categorization of potential harms that may be caused if the item fails. After categorizing the hazards according to the risk they imply, safety goals for the further development are derived in order to avoid any unreasonable risk. [ISO Part 3 clause 7].

The main objective of this activity is to identify all potential hazards caused by the item or in which the item is somehow involved, based on the item description and the rough item architecture, and to understand the risk of each such hazard. A common approach to the hazard analysis is to identify the potential malfunctions of the item and to analyze their influence onto the safety of the item in different operational situations that involve the item. You have to analyze the potential hazards implied by the occurrence of each malfunction during all relevant operational modes.

After finishing the hazard analysis, you should perform a risk assessment for each hazardous event. The combination of an operation mode, a malfunction and a hazard is called a hazardous event. For each such hazardous event, you apply the ISO 26262 risk graph. This results in the determination of a Automotive Safety Integrity Level (ASIL) for each identified hazard. The risk graph uses 3 input parameters, which are:

For each of the parameters, you should give an argumentation why you have chosen the specific value. This argumentation may include statistical data, reference cases of a similar events, references to commonly accepted publications and so forth. The argumentation is very important in terms of later development efforts.

The ISO 26262 risk graph method has to be applied for each hazardous event that has been identified during the hazard analysis. In the next step, you should provide a so called safety goal for each hazardous event. Imagine the safety goal as inverse of the hazard, i.e. the safety goal expresses how to reduce the risk to a tolerable level. Safety goals are not expressed in terms of technical solutions, but in terms of functional objectives. The safety goal "inherits" the ASIL from the hazardous event. In case multiple safety goals are similar to each other, the same safety goal can be shared between the hazardous events. The highest ASIL of those hazardous events that share the safety goal should be assigned to the resulting safety goal. If applicable, you can also specify a safe state for the safety goal (i.e. a particular state that achieves the safety goal).

The results of the hazard analysis and risk assessment should be reviewed to check for correctness and completeness. Additionally, you should document the results of the hazard analysis and risk assessment, the safety goals and the results review as a work product.

Safety goals are top-level functional safety requirements for the item. Having them, the more detailed functional safety requirements for each safety goal should be defined. ISO 26262 requires you to specify a functional safety requirement for each safety goal that has been defined. Please note that a single functional safety requirement can be applied for multiple safety goals. The safety requirements can now be detailed continuously. That means you can define a hierarchy of safety requirements with the top safety requirements contributing to the fulfillment of the safety goal. The primary artifacts you can use to derive the safety requirements are the preliminary item architecture, the functional concept, the operating modes and safety goals/safe states. According to ISO 26262 part 3, each functional safety requirement shall specify the operating modes, the fault tolerant time interval, the safe states, the emergency operation interval and potential functional redundancies.

ISO 26262 allows you to perform a so called ASIL decomposition. The concept behind that is that you can decompose a safety requirement into two safety requirements and implement those two requirements by two independent subsystems. The effect is a lower ASIL for each of the subsystems and therefore a reduced development effort for each of those subsystems. The term independent is the key here: you have to justify that the two subsystems are independent from each other. To justify the independence of those subsystems, you can perform an analysis of dependent failures. The analysis should be based on the architectural concept that was created during the item definition phase.

With the safety requirements defined, you can refine the rough item architecture. Basically you should specify which component of your item architecture implements which safety requirement. This step is referred to as allocation of safety requirements. Make sure, that all of the functional safety requirements are covered by at least one of the item components. You should perform a peer review of the safety requirements allocation.

As final activity of the concept phase, a safety concept document should be created. This document consists of all functional safety requirements, the warning and degradation concept as well as the allocation of functional safety requirements to the elements of the item architecture.

The system design for the item to be developed takes into account the functional requirements as well as the requirements defined in the functional safety concept. The safety requirements have to be assigned to the respective hardware or software system elements which implement the required safety functionality. [ISO Part 4 clause 7].

This phase has three main objectives:

The item architecture and the allocation of safety requirements on the elements of the item architecture should be used as the main input to this activity. In order to provide the system architecture, you should refine the item architecture. To do this, you describe the decomposition of components in the item architecture. Try to define hierarchies of system architecture and design models, i.e. a component at a higher level of abstraction is represented by a set of connected elements at a lower level of abstraction.

If failure modes and failure rates for such components are known, you should add them as properties to each component. Sensors for example can stop delivering the correct value, i.e. remain stuck at a specific value instead. Such information will be used for further safety analysis methods, e.g. Failure Mode and Effects Analysis and the Fault Tree Analysis.

The Failure Mode and Effects Analysis (FMEA) is an inductive safety analysis method for the identification of component failures for all components and the effects of these failures on the system behavior.

The Fault Tree Analysis (FTA) is a deductive safety analysis for the identification of relationships and dependencies between failure events and the detection of minimal sets of events which may lead to a top-level failure. Moreover, probabilities and importance for the failure event can be determined with FTA.

As result of these safety analysis activities new (technical) requirements should be created in the "Safety goals and Requirements" package.

After the system architecture has been finalized, you should define the allocation of software components to the system architecture elements. If you follow a model-based approach, you basically define software sub-systems with inputs and outputs. For these inputs and outputs, you should specify which input/output port of the system architecture will be connected to which input or output of the software components. In addition you should specify which ECU is going to execute which software component.

The various requirements and consistency rules defined by ISO 26262 have to be checked in the safety analysis process in order to argue on standard compliance.

System design models are linked to their requirements and to the safety analysis artifacts, e.g. FMEA and FTA. The traceability helps to identify points in the analysis which have to be revisited when changes in the requirements or system design occur.