Safe-RE Metamodel
| Concept |
Description |
Mission Requirement | It defines the purpose of the system according to the user needs. It is the source of Functional requirements, operational requirements and constraints. |
| Domain model | It consists of a conceptual model, such as a class diagram in the Unified Modeling Language (UML) that describes real-world concepts of the domain that will be manipulated and its behavior. This model can be used to communicate with non-technical stakeholders such as the customer as well as end users since it uses domain vocabulary. |
|---|
| Standard and guideline | They describe the information that should be specified, rules to be followed, documents to be produced by the company in order to certify a system by regulatory authorities. |
|---|
| Requirements specification | It contains all the requirements including hardware and software, constraints, and business rules of the system being developed, but not the specification of safety-related concepts.
|
|---|
| Safety integrity level | It corresponds to a range of safety integrity values that represent the probability of a safety-related system accomplish the specified safety functional requirements under all the defined conditions within a stated period of time. IEC 61508 defines four levels (1-4) where the 4th level is the highest of safety integrity and 1st is the lowest. |
|---|
| Assumption | It is a statement that reflect a common situation in the domain that is so ingrained into stakeholders general beliefs that it is unquestioned. Therefore, assumptions are internalized by individuals as part of the system operations. |
|---|
| Criteria | They include metrics to determine if the system is safe and percentage of requirements analyzed.
|
|---|
| Safety Goal | It is a high-level objective related to achieving safety in the system. Such goals can be refined during the development process varying the level of abstraction (details). |
|---|
| Artefact | It can be Safety Specification or Safety Specification Graph (SSG). The Safety Specification contains all information generated during safety analysis which can have models and descriptions in natural language. The SSG is an information model to record the results of the requirements and safety analysis, and their interrelationships. |
|---|
| Evidence | It is a kind of output whose aim is to demonstrate that the Hazard was properly treated. The Evidence is composed by File (produced along the safety analysis), Argument (reasons that justify why the system is acceptably safe for a specific application in a specific operating environment), and Safety Case (collection of arguments and files that prove that the system is safe). |
|---|
| SoftwareCritically | The criticality of a software product is determined at system level, based on the severity of the consequences of the system failures that the software can cause. |
|---|
| Component | System Requirements are allocated to some Component during safety analysis. A component can be a HardwareComponent (part of a larger piece of hardware or system) or SoftwareComponent (fragment of code). |
|---|
| Hazard | It is a system state that might, under certain environmental or operational conditions (Context) lead to different consequences: Accident, SafetyIncident or cause a Harm. It is associated with FunctionalRequirement. Hazard has eight attributes: Description, Severity, HazardProbability, NumberAffectedPeople, Recommendation, DetectionPhase, PeriodofExposure, and PossibilityAvoidingHazard. |
|---|
| Accident | It is an undesired and unplanned (but not) necessarily unexpected) event that results in (at least) a specified level of loss. |
|---|
| SafetyIncident | It is an event that involves no loss (or only minor loss) but with the potential for loss under different circumstances. On the other hand, a Harm can occur to Assets of the system or to the Mission. |
|---|
| Assets | It can be People, Property, Environment, Service. |
|---|
| HarmtoPeople | People in the system can be Human beings, roles played or organizations which can suffer with Death, Injury, Illness. |
|---|
| HarmtoProperty | It can be Destruction, Damage, Corruption, Theft, UnauthorizedAccess or UnauthorizedDisclosure. A Property has two attributes PropertyType and PropertyOwner. A PropertyType can be Tangible or NotTangible and the PropertyOwner can be Private, Public or Commercial. |
|---|
| HarmtoEnvironment | It can be Destruction, LossofUse or Damage. |
|---|
| HarmtoService | It can be Corruption, UnauthorizedUsage, AccidentalLossofService, DenialofService or RepudiationofTransaction. |
|---|
| HarmtoMission | It compromises the satisfaction of some system goals.
|
|---|
| SafetyRequirement | It describes a requirement related to system safety. It has the following attributes: Name, Description, satisfyStatus, validationStatus, and a Responsible. Such requirement can be of three types: Safety-significant requirement, Pure safety requirement, Safety constraint, and SafetyFunctionalRequirement. |
|---|
| Safety-significantRequirement | It is a normal functional, data, interface, and non-safety quality requirement that is relevant to the achievement of safety requirements. |
|---|
| PureSafetyRequirement | It describes what actions and/or constraints should or should not be performed to maintain the system in a safe state. |
|---|
| SafetyConstraint | It is an architecture or design constraint mandating the use of specific safety mechanism or safeguards. |
|---|
| SafetyFunctionalRequirement | It is a requirement that should be implemented to avoid the occurrence of hazards or to mitigate them. |
|---|
| SafetyRequirement | It is related to Component and FunctionalRequirement. |
|---|
| Severity of a hazard | It is an enumeration with the following options: Catastrophic (may cause death or system loss), Critical (may cause severe injury, severe occupational illness, or major system damage), Marginal (may cause minor injury, minor occupational illness or minor system damage), and Negligible (will not result in injury, occupational illness, or system damage). |
|---|
| HazardProbability | It can be Frequent (likely to occur frequently to an individual item, continuously experienced throughout the fleet or inventory); Probable (will occur several times during the life of an individual item, frequently throughout the fleet or inventory); Occasional (likely to occur sometime during the life of an individual item, several times throughout the fleet or inventory); Remote (unlikely to occur but possible during the life of an individual item; unlikely but reasonable expected to occur in a fleet or inventory); and Improbable (extremely unlikely to occur to an individual item; possible for a fleet or inventory). |
|---|
| NumberAffectedPeople | It will depend on the consequences and severity level of the hazard. However, it is import to estimate this number early as well as the PeriodofExposure to the hazardous situation. |
|---|
| Recommendation | It can be classified in the following categories: modification of allowed use, modification of the specification, and modification of the design.
|
|---|
| DetectionPhase | It is another important characteristic of a hazard to be specified. It will allow the management to produce reports and better plan the system development. A hazard can be detected in the Requirements, Design, Development, Test or Maintenance phase. |
|---|
| PossibilityAvoidingHazard | It describes the probability of mitigating the hazard and avoiding its consequences.
|
|---|
| MitigationStrategy | It should be defined to minimize the consequence or probability of the hazard. It has the following attributes: Description, Responsible, and Refinement. It can be Reaction or Detection through mechanisms (Timeout, ValueOutsideValidscope). Examples of Reaction can be ReduceRisk, Elimination, Recovery, Analysis, and ProvideWarning. |
|---|
| CauseHazard | A Hazard also has at least one Cause. It occurs due to EnvironmentalHazard, ProceduralHazard, InterfaceHazard, HumanFactor or SystemCause.
|
|---|
| Failure | It is an event where a system or subsystem component does not exhibit the expected external behavior. It has a Probability and it is related to Hardware (Electronic or Mechanical) or Software. |
|---|
| Risk | It is a combination of consequence (severity hazard) and likelihood of the hazard, i.e. risk = probability hazard x severity hazard. A risk can be of four types: EquipmentUnderControlRisk, ResidualRisk, TolerableRisk, and TargetRisk. |
|---|
| EquipmentUnderControlRisk | It is a risk arising from the equipment under control or its interaction with the control system. |
|---|
| ResidualRisk | It is a risk remaining after protective measures have been taken. |
|---|
| TolerableRisk | It is a risk which is accepted in a given context based on the current values of society. |
|---|
| TargetRisk | It is a risk that is intended to be reached for a specific hazard taking into account the EquipmentUnderControlRisk together with safety-related systems and the other risk reduction measures. |
|---|