Dependability

Dependability of a system is the system's ability to ensure service failures are at a level of frequency and severity that is acceptable. Dependability includes several aspects, namely Availability, Reliability, Safety, Integrity and Maintainability. The Dependability package includes support for defining and classifying safety requirements through preliminary Hazard Analysis Risk Assessment, tracing and categorizing safety requirements according to their role in the safety life-cycle, formalizing safety requirements using safety constraints, formalizing and assessing fault propagation through error models, and organizing evidence of safety in a Safety Case.<br/><br/>The support for safety is designed to support the automotive standard for Functional Safety, ISO/DIS 26262.<br/><br/>FunctionalSafetyConcept Functional Safety Concept<br/>FunctionPort -<br/>FunctionPrototype -<br/>FunctionType -<br/>Ground Indirect: Used to provide a ground in a Safety Case<br/>HardwareComponentPrototype -<br/>HardwareComponentType -<br/>HardwarePin -<br/>Hazard Hazard<br/>HazardousEvent HazardousEvent<br/>Identifiable -<br/>InternalFaultPrototype Indirect: Used to declare internal faults of components of the Error Model.<br/>Item Item<br/>LifecycleStageKind Indirect: Used to define the lifecycle stage of a particular safety case.<br/>Mode Used to represent Operating Mode including Safe State, <br/>OperationalSituation OperationalSituation<br/>ProcessFaultPrototype Indirect: Used to represent process faults in components of an error model. This allows declaration of required development rigor in terms of ASIL through a safety constraint.<br/>QuantitativeSafetyConstraint Used to define Failure Rate<br/>Rationale Indirect: Used to declare Rationale in a safety case<br/>Requirement Used to represent Functional, technical, hardware and software requirements<br/>RequirementsContainer Used to organize requirements in a structure<br/>RequirementsRelationship Used to relate between requirements <br/>SafetyCase Indirect: The safety case can be used to organize the ISO26262 related information showing that the system is safe.<br/>SafetyConstraint Used to define the ASIL level on a particular fault or failure<br/>SafetyGoal Safety Goal<br/>SeverityClassKind Severity enumeration S0, S1, S2 or S3<br/>SystemModel -<br/>TechnicalSafetyConcept Container element for the Technical Safety Requirements allocated to architectural elements, that together form the Technical Safety Concept<br/>TraceableSpecification -<br/>UseCase Used in the role Operational Situation for Hazardous event<br/>Warrant Indirect: Represents warrant in a safety case<br/>VehicleFeature A set of Vehicle Features, realized by architectural elements, makes up the Item <br/>