Hazard Classification Inheritance in a Safety Profile
Northlake Systems is building a profile for its safety process. The profile defines «Hazard» extending SysML «Requirement» with properties severity (Low/Medium/High) and likelihood, and a «SafetyGoal» stereotype extending «Requirement» with a property targetASIL. Engineers created 320 requirements in a package «SystemRequirements». A derived requirement R-114 refines R-042 via «deriveReqt». R-042 is stereotyped «Hazard»; R-114 has no stereotype and validation reports 'Hazard.severity is unset' only on R-042. The safety lead wants every derived requirement to inherit the hazard classification automatically and insists the profile be reused on a supplier's model, which uses a different requirements package name. A tool vendor says stereotype inheritance across «deriveReqt» is not supported. The team proposes to make «Hazard» extend «Class» instead, or to duplicate the stereotype application to all children, or to move classification out of requirements into a separate hazard library.
1. Why does the current profile fail to propagate the hazard classification to R-114, and why is 'make Hazard extend Class' not a safe fix? Explain the metamodel semantics.
Read the worked answer
Stereotypes extend metaclasses, not individual model elements, and their properties are stored on each stereotype application. «deriveReqt» is a dependency between requirements, not a generalization, so no property values flow from R-042 to R-114. The validation message appears only on R-042 because only R-042 carries the «Hazard» application. Making «Hazard» extend «Class» is risky for three reasons. First, SysML Requirement is itself a kind of Class, so the extension would either be too broad, applying to blocks and other classes, or would still require a separate application on each requirement. Second, if the extension is marked required, every Class in the model would need the stereotype, which is unworkable. Third, it changes the profile's metaclass contract and invalidates existing applications. Duplicating the stereotype on every child is also fragile: the 320 requirements would need manual maintenance, and a change to severity on the parent would not propagate. The root issue is that hazard classification is being treated as an inherited requirement property when it is a separate classification of the item being analyzed.
2. Recommend a modeling pattern that gives the safety lead a reliable, queryable hazard classification for every derived requirement without duplicating stereotype applications.
Read the worked answer
Move the classification off the requirement and onto a hazard item in a model library. Define «Hazard» as a stereotype extending «Block», or a «Class» used only as a classification record, with severity, likelihood, and targetASIL. Create one hazard block per hazard and put the library under configuration control. Each requirement, including derived ones, gets a «satisfy» or a custom «classifiedBy» dependency to the hazard block. R-042 and R-114 both link to the same hazard, so no inheritance is needed. If a report must show the effective classification on a derived requirement, implement a model query that traverses «deriveReqt» from R-114 to R-042 and then to the linked hazard, and materializes the result in a view or table. Do not encode the query result as a stereotype value, because it would become stale. This pattern also separates safety analysis from requirements management: the hazard library can be reused by the supplier, and requirements remain simple. Validation can check that every requirement in the safety package has at least one hazard link, rather than checking a stereotype property on each element.
3. The supplier uses a different package name and a different profile version. What must be stabilized so the classification survives the exchange, and what does that imply about profile ownership and versioning?
Read the worked answer
Stereotype applications are stored by reference to the profile element, usually by qualified name. Renaming the profile package, or supplying a copy with a different package path, can break the link or create two distinct «Hazard» stereotypes that the tool will not unify. Stabilize the profile package name and give the profile an explicit version. Put the profile in a library package that is imported, not copied, and apply it once at the model root. The supplier should import the same profile version; if their package name differs, use a model-level import or alias, and test with a small exchange model. Record the profile version in the CM baseline. If the supplier cannot use the same version, define a mapping between the two versions and validate that the mapped properties are present; do not silently accept two stereotype identities. Ownership should sit with the safety process, not with either project, so both sides consume a released profile.