Assignment of a requirement to an architectural element. medini analyze supports the allocation of (safety) requirements to system design models (e.g. SysML, MATLAB Simulink) via traces. Note that the ISO term should not be mixed up with the concept of allocation relations in SysML, which also exists to allocate elements across SysML models.

Representation of the structure of the item or systems or elements that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of functions to hardware and software elements. Architectures are represented in either SysML or by imported MATLAB Simulink in medini.

Apportioning of safety requirements redundantly to sufficiently independent elements with the objective of reducing the ASIL of the elements. The safety requirements editor provides a dedicated relation for this purpose.

One of four levels to specify the items or elements necessary requirements of ISO 26262 and safety measures for avoiding an unreasonable residual risk with D representing the most stringent and A the least stringent level. ASILs can be determined in the HARA and consistently inherited to safety goals, safety requirements, and further to SysML model elements.

Failure of an element of an item causing other elements of the same item to fail.

Failure of two or more elements of an item resulting from a single specific event or root cause.

Non-system level element that is logically and technically separable and is comprised of more than one hardware part or of one or more software units. The SysML editor provides a "Component" category to tag blocks and parts as component.

NOTE A component is a part of a system and consists of software units or hardware parts.

Avoidance of the specified harm or damage through the timely reactions of the persons involved.

Failures whose probability of simultaneous or successive occurrence cannot be expressed as the simple product of the unconditional probabilities of each of them.

Strategy for providing safety by design after the occurrence of failures.

Failure, resulting from the combination of two independent faults, that leads directly to the violation of a safety goal.

NOTE Dual point failures that are addressed in ISO 26262 include at least those where one fault affects a safety related element and another fault affects the corresponding safety mechanism intended to achieve or maintain a safe state.

Individual fault that, in combination with another independent fault, leads to a dual point failure.

NOTE A dual point fault can only be recognized after the identification of dual point failure e.g. from cut set analysis of a fault tree

System that consists of electrical and/or electronic elements, including programmable electronic elements.

System or part of a system including components, hardware, software, hardware part, and software units. The SysML editor provides a category to distinguish different element types (quasi stereotype) and "Element" is used as default.

Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. In medini, the Error failure type loosely corresponds to errors of ISO 26262 if they are related to software, but can be used in a broader sense to model any unexpected discrepancy.

NOTE 1 An error can arise as a result of unforeseen operating conditions or due to a fault within the system, subsystem or component being considered.

NOTE 2 A fault can manifest itself as an error within the considered element and, at the end of its latency, the error can cause a failure.

State of being in an operational situation that can be hazardous if coincident with the failure mode under analysis. Exposure values can be pre-configured in operational situation catalogs and used in the HARA editor and driving situation matrix.

Termination of the ability of an element or an item to perform a function as required. In medini analyze the four specialized failure classes are distinguished: Hazards, Malfunctions, Failure Modes, and Errors. Please refer to the analyze user guide for more details.

NOTE 1 Termination is a reduction in, or loss of, ability of an element or an item to perform a function as required.

NOTE 2 There is a difference between to perform a function as required (stronger definition, use-oriented) and to perform a function as specified , so a failure can result from an incorrect specification.

Manner in which an element or an item fails. Failure Modes in medini can be modelled at structural elements in SysML and quantified by a failure rate.

Density of probability of failure divided by probability of survival for a hardware element. medini uses a constant failure rate model in FIT (Failure In Time), which 1 failure in 10^9 hours.

Abnormal condition that can cause an element or an item to fail. Faults can be modelled in FTA or using the "Failure Mode" concept in medini.

Specification of the intended functions and their interactions necessary to achieve the desired behavior.

NOTE The functional concept is developed during the concept phase.

Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.

Specification of the functional safety requirements, with associated information, their assignment to architectural elements, and their interaction necessary to achieve the safety goals.

Specification of implementation-independent safety behavior, or implementation-independent safety measure, including its safety-related attributes.

NOTE 1 A functional safety requirement can be a safety requirement implemented by a safety-related E/E system, or by a safety-related system of other technologies, in order to achieve or maintain a safe state for the item taking into account a determined hazardous event.

NOTE 2 The functional safety requirements might be specified independently of the used technology in the concept phase of product development. They are detailed into the technical safety requirements after concept phase.

Hardware element whose function cannot be further sub-divided. Hardware parts are modeled in SysML and can be imported form BOM.

EXAMPLE Resistor, integrated circuit, micro-controller, capacitor, bus, cable, connector

Physical injury or damage to the health of people.

Potential source of harm. Hazards are first-class modeling concepts in medini analyze and referenced from the HARA or FMEA.

Method to identify and categorize hazardous events of items and to specify safety goals and ASILs related to the prevention or mitigation of these hazards in order to avoid unreasonable risk.

Combination of a hazard and an operational situation. In medini each entry (row) in the HARA editors represents a hazardous event, linking malfuction(s) and hazards based on an operational situation. A hazardous event is classified by Severity, Exposure, and Controllability.

Absence of dependent failure between two or more elements that could lead to the violation of a safety requirement; or organizational separation of the parties performing an action.

NOTE Independence is a characteristic associated with ASIL decomposition.

Failures whose probability of simultaneous or successive occurrence can be expressed as the simple product of their unconditional probabilities.

ASIL resulting from the hazard analysis or the ASIL resulting from a preceding ASIL decomposition.

NOTE The initial ASIL is the starting point for ASIL decomposition or further ASIL decomposition.

System or array of systems or a function to which ISO 26262 is applied. The Item Defintion is a first-class concept in the ISO 26262 safety domain profile of medini analyze.

Failure or unintended behavior of the item with respect to the design intent for this item. This is modeled using Malfunctions in medini.

Failure, resulting from the combination of several independent faults, which leads directly to the violation of a safety goal.

Individual fault that, in combination with other independent faults, leads to a multiple point failure.

NOTE A multiple point fault can only be recognized after the identification of multiple point failure e.g. from cut set analysis of a fault tree.

Process of creating an item having previously unspecified functionality, a novel implementation of an existing functionality, or both.

Perceivable functional state of an item or element.

EXAMPLE system off, system active, system passive, degraded operation, emergency operation

Scenario that may occur during a vehicle's life. Operational situations preconfigured as catalogs at project level and used in the HARA.

EXAMPLE Operational situations can include driving, parking, and maintenance.

failure that may occur unpredictably during the lifetime of a hardware element and that follows a probability distribution

NOTE Random hardware failure rates can be predicted with reasonable accuracy.

Combination of the probability of occurrence of harm and the severity of that harm.

Operating mode of an item without an unreasonable level of risk. The safe state is described at the safety goal in medini.

EXAMPLE intended operating mode, degraded operating mode or switched-off modes

Set of elements and their interaction to fulfill the safety requirements, including redundancy and independence concepts.

Argument that the safety goals for an item are complete and satisfied by evidence compiled from work products of the safety activities during development

NOTE Safety case can be extended to cover safety issues beyond the scope of this standard.

Policy and strategy used within an organization to support the development, production, and operation of safety related systems.

Top-level safety requirement as a result of the hazard analysis and risk assessment. First-class concept in the safety requirements module of medini.

NOTE 1 The negation of a safety goal leads to the top event of further safety analyses (e.g. FTA).

NOTE 2 The existence of several safety goals for one item is possible. One safety goal can be related to several hazardous events.

Plan to control and guide the safety activities of a project including dates, milestones, tasks, deliverables, responsibilities and resources .

NOTE The objective of a safety plan is to ensure that a developed item will fulfill the safety goals.

Assurance, based on examination and tests, that the safety goals are sufficient and have been achieved.

NOTE ISO 26262-4 provides suitable methods for validation.

Measure of the extent of harm to an individual in a specific situation.

Failure that results from a single point fault and leads directly to the violation of a safety goal.

Fault in an element that is not covered by a safety mechanism and that leads directly to the violation of a safety goal.

Implementation of one or more logically and technically separable functions in software.

NOTE A software component consists of one or more software components, or software units, or both. Within the software architecture software components are realised by partitions and tasks.

Set of elements, at least sensor, controller, and actuator, in relation with each other in accordance with a design.

NOTE An element of a system can be another system at the same time.

Failure of an element or item that is caused in a deterministic way during development, manufacturing, or maintenance.

NOTE Systematic failures can be prevented by applying design measures or production process changes on this element or item.

Specification of the technical safety requirements to implement and to allocate them to the system design.

Requirements derived from the associated functional safety requirements to provide their technical implementation.

Fault that occurs once and subsequently disappears. Transient faults are modelled as Failure Modes in medini with kind TRANSIENT, they receive their own transient failure rate.

Risk judged to be unacceptable in a certain context according to valid societal moral concepts.