Uni-REPM Tool

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.