glossary: rework after review

Signed-off-by: Simone Weiß <[email protected]>

Author: simone-weiss

docs/glossary/index.md

@@ -1,6 +1,6 @@
 # Glossary
 
-The following list contains Terms and their meaning used in ELISAs workgroups, workshops, meetings and other activities.
+The following list contains terms and their meaning used in ELISA's workgroups, workshops, meetings and other activities.
 
 Please note:
 
@@ -13,29 +13,29 @@ Please note:
 | ASIL (Automotive Safety Integrity Level) | A classification system defined in ISO 26262 for the automotive industry. It categorizes the risk levels of potential hazards based on their severity, exposure, and controllability. ASIL helps determine the necessary safety measures and requirements to ensure compliance with the standard. It is derived from the Safety Integrity Level (SIL) concept in IEC 61508. |
 | Bug | An observable difference between what the software is intended to do and what it does. Other name is defect. Reference SWEBOOK.v4 p.44 |
 | Code centric | A development process often used in open source and contrasting the V-model. |
-| Component |  An independent unit with well defined interfaces and dependencies that can be composed and deployed independently. Reference SEWBOOKv4 p. 94 |
-| Decomposition | In General the process of breaking down complex systems into simpler parts. Functional Safety Decomposition is a strategic approach that breaks down a safety requirement into redundant safety requirements allocated to independent elements. |
+| Component |  An independent unit that can be composed and deployed independently. Ideally the unit has well defined interfaces and dependencies. Reference SEWBOOKv4 p. 94 |
+| Decomposition | In general the process of breaking down complex systems into simpler parts. Functional Safety Decomposition is a strategic approach that breaks down a safety requirement into redundant safety requirements allocated to independent elements. |
 | Development processes | A series of steps or activities undertaken during the development of software, including planning, analysis, design, implementation, testing, deployment, and maintenance.|
 | DAL | Short for Development Assurance Level (DAL) defined in ARP4754, determined from the safety assessment process and hazard analysis by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers into No Effect, Minor, Major, Hazardous and Catastrophic. |
 | DO-178C | DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities approve all commercial software-based aerospace systems. |
-| Element |  Very generic term that is used to refer for example a basic unit or component within a system, but is used inconsistently. |
+| Element |  Very generic term that is used to refer for example to a basic unit or component within a system, but is used inconsistently. |
 | Failure | Termination of the ability of a system to perform a required function or its inability to perform within previously specified limits; an externally visible deviation from the system’s specification. Reference SWEBOOKv4 p. 248|
-| Fault | An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs o be either repaired or replaced. Reference SWEBOOKv4 p. 248 |
+| Fault | An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs or be either repaired or replaced. Reference SWEBOOKv4 p. 248 |
 | Functional safety | The part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, systematic errors,hardware failures and operational/environmental stress. |
-| Functional safety assessment |  Required, independent investigation, based on evidence, to determine if a System meets its required level of functional safety and achieves its target SIL. |
+| Functional safety assessment | Independent investigation, based on evidence, to determine if a system meets its required level of functional safety and achieves its target SIL (or similar integrity goal). |
 | Hazard | A potential source of harm. Among this are injuries, environmental or other damage. |
 | Incident |  Defect or malfunction in a system that could lead to an unacceptable risk. |
 | IEC 61508 | International standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES). It is a risk-based standard, therefore the risk of hazards is qualitatively assessed and measures to detect, avoid, control or mitigate those are defined. |
 | ISO 26262 | A standard that specifies the safety requirements for electrical and/or electronic systems within production automobiles defined by functional safety. |
-| Item | Safety-related product or system intended to perform a safety function within a larger system. |
+| Item | Term used by ISO 26262 to describe a safety-related product or system intended to perform a safety function within a larger system. |
 | Lifecycle | Stages that a product goes through from its inception to retirement, including development, production, operation, and end of life.|
-| Mixed-criticality | A system containing computer hardware and software that can execute several applications of different criticality, such as safety-critical and non-safety critical, or of different safety integrity level (SIL). | 
+| Mixed-criticality | A system containing hardware and/or software that can execute several applications of different criticality, such as safety-critical and non-safety critical, or of different safety integrity levels (SIL). | 
 | Proven in use | Method of ensuring the reliability and safety of a system by demonstrating its performance over time under actual operating conditions. PIU for short is an argument that a reliable operating history demonstrates fitness for safety applications.|
 | Quality Management | Performing processes and activities that determine quality policies, objectives and responsibilities so the project will satisfy the needs for which it was undertaken. Reference SWEBOOKv4 p. 210 |
 | Reliability | Degree to which a system or software performs specific functions under specified conditions for a specified period.  Reference SWEBOOKv4 p. 176 |
-| Reproducible |  Results obtained by an action (e.g., building or executing Software) should be achieved again in the exact same fashion upon re-performing the action. |
-| Requirement | A condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear  of a condition to be satisfied. A specification or spec is a set of requirements that is typically used by developers in the design stage of product development and by testers in their verification process. |
-| Risk | Relation or Likelihood of the hazardous event and the event consequence severity. The risk is reduced to a tolerable level by applying safety functions which may consist of E/E/PES, associated mechanical devices, or other technologies. |
+| Reproducible |  Results obtained by an action (e.g., building or executing software) should be achieved again in the exact same fashion upon re-performing the action. |
+| Requirement | A condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear condition to be satisfied. A specification or spec is a set of requirements that is typically used by developers in the design stage of product development and by testers in their verification process. |
+| Risk | Relation or likelihood of the hazardous event and the event consequence severity. The risk is reduced to a tolerable level by applying safety functions which may consist of E/E/PES, associated mechanical devices, or other technologies. |
 | Safe | Generally refers to being free from harm, danger, or risk. |
 | Safe Linux | Implies that safety can be allocated to the system which involves Linux, but there is no direct safety argumentation applied to Linux, safety is achieved in other system layers. |
 | Safe state | A state an E/E system enters to avoid unreasonable risk. It may involve degrading or disabling functions to mitigate harm from a malfunction or fault. |
@@ -46,7 +46,7 @@ Please note:
 | Safety life cycle |  A systematic approach of managing safety considerations during the lifecycle. |
 | Safety Linux | This means that safety argumentation is directly allocated to Linux as the operating system or the Linux Kernel. Hence Linux itself is subject of safety assessments to meet different safety integrity levels (SIL).  |
 | Safety manual | A document that shall provide all relevant information about the Safety functionality provided by an element and how to use it correctly including proper use, limitations, constraints and required activities for the integration and/or usage of elements. |
-| Safety mechanism |  A technical solution to detect, avoid, control, or mitigate the harmful effects of failures. Examples are redundancy, Fault detection and handling among others | 
+| Safety mechanism |  A technical solution to detect, avoid, control, or mitigate the harmful effects of failures. Examples are redundancy, fault detection and handling among others. | 
 | Safety mitigation | Is the reduction of something harmful that has occurred or the reduction of its harmful effects. |
 | Safety Plan | A formal document outlining a project's approach to safety management, including objectives, responsibilities, methods. |
 | Safety requirement | Define safety mechanisms and other safety measures to minimize the risks to reach the Safety Goal(s). There may be a hierarchical approach to requirements as in ISO 262626, starting with Safety Goals and progressing through Functional, Technical, and Software Requirements. |
@@ -58,6 +58,6 @@ Please note:
 | System | Is 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. |
 | System Design | Is the overall system architecture, hardware architecture, software architecture, modules, interfaces, data management, and communication among modules. Reference SWEBOOKv4 p.316 |
 | Test | A procedure intended to assess whether an item or system meets its specified requirements; includes various types such as unit tests, integration tests, acceptance tests, etc. |
-| V-Model | A development process, often considered an extension of the Waterfall model. The left side deals with specification and design, the V bends at code implementation and on the right side of the “V” various levels of testing are executes. This model demonstrates the relationships between each phase of the development lifecycle and its corresponding testing phase. The horizontal and vertical axes represent the progression of time or project completeness (left-to-right) and the level of abstraction – starting with the most coarse-grained concepts at the top. The V-Model is not directly demaneded in standards like IEC 61503, but many demands of the software development lifecycles referenced referenced in it are related to it. |
+| V-Model | A development process, often considered an extension of the Waterfall Model. The left side deals with specification and design, the V bends at code implementation and on the right side of the “V” various levels of testing are executes. This model demonstrates the relationships between each phase of the development lifecycle and its corresponding testing phase. The horizontal and vertical axes represent the progression of time or project completeness (left-to-right) and the level of abstraction – starting with the most coarse-grained concepts at the top. The V-Model is not directly demanded in standards like IEC 61503, but many demands of the software development lifecycles referenced referenced in it are related to it. |
 | Validation | Ensures the product fulfills its specific intended purpose. It is defined as "the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements." Reference SWEBOOKv4 p.257 |
 | Verification | Ensures that the product is built correctly in that the output products of a life cycle phase meet the specifications imposed on them in previous phases. Verification is defined as “the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase". (Reference SWEBOOKv4 p.257) May  involve peer reviews, inspections, and testing. |