Hi,

I recently expanded upon my post about "Safety is a system property" [1] in an article [2], which includes the glossary that I have shared below.

There's a saying (attributed to George Bernard Shaw) that "Britain and America are two nations divided by a common language". I sometimes feel this way when discussing software engineering ideas with people from different industries or backgrounds, especially when discussing safety. What I understand by 'unit testing' may be very different to what you mean; when there's not a 'right answer', it becomes important for us to establish a common understanding.

The terminology in my glossary is borrowed heavily from the STPA Handbook [3], and focusses on a specific topic ('safety is a system property'), but it also has value outside that specific topic area, as it isn't tied to a specific domain or safety standard.

I'm not proposing this as an ELISA glossary; I share it only as an example. This is what I had in mind when I talked about making an 'ontology' for ELISA in my previous post: a common vocabulary and a conceptual model that we can use when reasoning about safety with respect to Linux (and other open source software).

So why not just use some existing terminology from a safety standard?

Well, I am wary of this, partly because there are issues of accessibility and copyright, but also because these definitions may be heavily influenced by a standard's approach and/or domain. See the ISO 26262 definitions [4] for an example: some of the key terms (e.g. Item) are very firmly rooted in the automotive domain (and the way the its supply chain works).

If we define and continue to build a set of generic terms to frame our discussions in ELISA, then we can still correlate them with the equivalent terms from specific standards (see SEooC below for an example). And where those standards (or other relevant sources) do have terms that fit our understanding and use of a concept, then I will be more than happy to use them!

I'm over-committed with work for the rest of this month, but I'd be happy to make a start on this in April, if anyone else can see the value in it - and are willing to contribute or review!

Regards,

Paul

PS: Sorry @Elana: I haven't defined 'safe' or 'safety' :-)

[1] https://lists.elisa.tech/g/devel/message/1384
[2] https://www.codethink.co.uk/articles/2021/safety-system-property/
[3] https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf
[4] https://www.iso.org/obp/ui/#iso:std:iso:26262:-1:ed-2:v1:en


Glossary
--------

abstract context: A system context that is partial, provisional or conditional, where missing or unspecified aspects of the context are described using assumptions or requirements. This may be contrasted with a concrete context.

component: A discrete element or part of a system, or systems. A component in one frame of reference may be considered a system in another.

concrete context: A system context that corresponds to a real-world system (e.g. a product) with specified components and environment. This may be contrasted with an abstract context.

constraints: Unambiguous criteria pertaining to the operation of a system. Constraints are described using “must” or “must not” rather than “shall"; a distinction is made between requirements (system goals or mission) and constraints on how those goals can be achieved.

environment: An aspect of the system context, which may include any external factor that may have an effect upon it. Depending on the nature and boundaries of the system, this might be anything that is external to it: an aspect of the physical world (e.g. weather) for a sensor, or the CPU hardware for an operating system.

failure: The manifestation of a fault: something that prevents a component or system from fulfilling its intended purpose.

hazard: A system state or set of conditions that, together with a particular set of worst-case environmental conditions, will lead to a loss.

loss: An undesirable outcome associated with the operation of a system, involving something of value to its stakeholders (users, producers, customers, operators, etc).

process: A formalised set of practices that are undertaken as part of a development lifecycle.

risk: Describes the probability of an undesirable outcome (one that may lead to a loss) and the severity of the consequences.

safety measure: An activity or technical solution that is intended to prevent a hazard, reduce the probability of the associated risk, or minimise the severity of the consequences.

SEooC: Safety Element out of Context. In the ISO 26262 standard, this term is used to describe a component that is subjected to a safety certification process for an abstract context. See the ISO 26262 definition for more information.

sufficient: What is considered acceptable for a given domain or category of systems when considering what safety measures need to be undertaken to identify or mitigate risks, and what criteria these need to satisfy.

system: A set of components that act together as a whole to achieve some common goal, objective, or end. A system may contain subsystems and may also be part of a larger system. It may have both hardware and software components.

system context: A defined scope of analysis, which encompasses a system (or component), its intended purpose and the factors (including its environment) that may have a bearing upon that purpose. Some of these factors may be implied by the identified purpose (e.g. a car driven on public highways is subject to weather and traffic regulations).

tool: A software or hardware solution that is used as part of the development process for a system or component. If a tool is responsible for providing a safety measure (e.g. constructing or verifying a component), then it has a bearing on safety, even though it does not form part of the resultant system or component.