# IEC 63187: Engineering Safety into Complex Defense Systems

James Inge, Katia Potiron, Phil Williams, Bertrand Ricque

► To cite this version:

James Inge, Katia Potiron, Phil Williams, Bertrand Ricque. IEC 63187: Engineering Safety into Complex Defense Systems. Safety in an Agile Environment: the 2023 Annual International Systems Safety Summit and Training, International System Safety Society, Aug 2023, Portland (OR), United States. hal-04629374

HAL Id: hal-04629374

https://hal.science/hal-04629374v1

Submitted on 29 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
IEC 63187: Engineering Safety into Complex Defense Systems

James R Inge, MEng MSc PgDip CEng MIET MBCS; UK Ministry of Defence; Bristol, UK

Katia Potiron, PhD; Nexter Systems; Bourges, France

Phil Williams, MSc BSc(Hons) CEng FIET; Engineer for Safety Ltd; East Sussex, UK

Bertrand Ricque, EurIng; Safran Group; Paris, France

Keywords: systems safety, systems engineering, IEC63187, IEC61508, ISO/IEC/IEEE15288

Abstract

IEC 63187 is the new defense sector safety framework being developed by the International Electrotechnical Commission. Defense applications are typically complex systems, built from individual elements that may also be both technically and managerially complex themselves: developed under different lifecycle models by different suppliers, to different standards, at different times. Defense systems are also subject to dynamic changes of risk, as the context of their deployment changes. Existing safety standards are not well suited to this level of complexity. They tend to be aimed at single organizations rather than complex hierarchies, and to focus on the failures of system elements, rather than important emergent properties of the overall system. The new international standard in development, IEC 63187, tackles these problems using modern systems engineering principles. It applies the ISO/IEC/IEEE 15288 lifecycle processes to supplement IEC 61508 and other safety standards, proposing an approach that allows requirements to be tailored to the risk and managed across multiple system layers. This framework is designed to be open, for compatibility with different lifecycle models, different national approaches to assurance and risk acceptance, and different realization standards for individual system elements. This paper discusses the motivation, principles and approach of IEC 63187 and gives an update on the draft's progress through the standardization process.

Main Body

The International Electrotechnical Commission (IEC) is currently drafting a new international standard titled ‘Functional Safety – Framework for safety critical E/E/PE systems for defence industry applications’. ‘E/E/PE’ relates to Electrical, Electronic and Programmable Electronic systems, including software and complex electronic hardware. Such systems are increasingly prevalent in defense applications, even in roles where mechanical systems have traditionally been used. IEC 63187 aims to help suppliers demonstrate that complex defense products, systems and services incorporating E/E/PE are acceptably safe for their customers to operate. This paper explains why a new international standard is necessary in this area, and introduces some of the key innovations in its approach, building on feedback received by the authors on previous presentations of the work (Ricque, Joguet, Brindejonc, Semeneri, & Potiron, 2022), (Inge & Williams, 2023).
## The Challenge of Defense Systems

Systems in the defense sector often have characteristics that are not well catered for by existing functional safety standards:

**Managerial complexity:** Defense applications are often 'systems of systems' in several of the senses used in the Systems Engineering Body of Knowledge (Henshaw, Dahmann, & Lawson, 2022), in that the system elements that make them up are separately defined, acquired and integrated. These elements may be a combination of bespoke new developments, off-the-shelf components, customizations of existing designs, and 'legacy' equipment that is already in service. The different elements are often specified and procured separately from different suppliers at different times, and increasingly may be supplied as services rather than traditionally acquired hardware. Hence, they may be at different stages in their product life cycles when brought together to deliver an overarching capability. Existing functional safety standards tend to be limited in scope, and are often intended to be applied within a single organization, rather than across a complex supply chain.

**Technical complexity:** Major defense capabilities are often made up of numerous system elements that are complex systems in their own right. Since the 1960s, systems engineering techniques have been developed to manage this complexity, in defense and other industries. However, current functional safety standards do not necessarily apply systems engineering principles and anticipate recursive application through a hierarchy of systems. Safety Integrity Levels (SILs) and similar concepts become difficult to apply in complex systems hierarchies: it becomes hard to decompose SILs and assign them over multiple layers of the hierarchy, especially when the different system elements may be managed separately.

There is also a tendency for standards to focus mainly on guaranteeing safety by controlling the impact of failures of individual system elements. However, in complex systems, emergent properties are a concern, and it is possible for systems to behave unsafely without failures of their individual elements.

**Dynamic risk:** The hazards and potential losses involved in military systems are dependent on the context of operation, and operators need to balance the safety and the capability of the system. While this is true of most systems, the operating context for military systems can change frequently and rapidly during their operation, resulting in changes to safety objectives and trade-offs. For example, changes to the threat posed by hostile actors may mean that it is necessary to compromise some safety objectives to complete the mission. There is often an implicit assumption in functional safety standards that the level of risk will remain largely constant.

**Customer determination of risk acceptability:** in many other industries, the acceptable level of risk is determined to a certain extent by civil regulation; or the organization supplying the product can set their own risk appetite. In defense, often the arbiter of risk acceptability is the organization acquiring the system, normally a national defense ministry or an agency working on their behalf. Civil safety legislation often explicitly excludes defense systems from its scope, or gives powers to the government to exempt particular applications in the interests of national security. Functions performed by defense systems are sometimes also uniquely military in nature, and not well covered by civil product safety standards. Defense procurement organizations have a dilemma: they are
generally held accountable by their government, so need assurance from suppliers that the
equipment they procure will be safe to operate. However, they do not wish to overly constrain
implementation options, limit operational capability or impose unnecessary costs on their projects.

While all of these characteristics are common in systems found in the defense sector, in practice
they could also be found in other regulated sectors using complex technology or where the
interactions of system elements are complex. IEC 63187 aims to address defense sector issues;
however, there is nothing inherently defense-specific in the normative requirements it sets.

The IEC 63187 approach

When developing a complex system, safety is neither something that can be managed
independently, nor the end goal of the system. It is an emergent system property rather than a
separate feature that can be designed in. Similarly, safety is not the outcome of a single technical
or managerial process, but the result of the multi-disciplinary combination of activities that go into
designing, manufacturing, deploying and operating the system.

IEC 63187 recognizes this, and also recognizes that a standardized body of good practice already
exists in disciplines like systems engineering, risk and quality management, which may not be
specifically aimed at managing safety, but nonetheless supports delivery of safe socio-technical
systems. Rather than attempting to duplicate these standards, IEC 63187 builds on them to explain
how they can be extended using systems thinking and systems engineering to produce an effective
framework for managing the safety aspects of a complex system.

<figure><img src="image_2.png" /><figcaption>Figure 1 — IEC 63187 pedigree</figcaption></figure>

In particular, IEC 63187 builds on the systems engineering framework of ISO/IEC/IEEE 15288 (ISO, 2015). Although IEC 61508 (IEC, 2010) is the ‘horizontal standard’ or ‘Basic Safety Publication’ for functional safety of E/E/PE systems,<fnref n="1" /> the detailed approach described in IEC 61508 only fits those systems that match the functional concept described in the standard. Instead of building directly on IEC 61508, IEC 63187 aligns more directly to ISO/IEC/IEEE 15288. It

<footnote n="1">¹ Meaning that it gives “fundamental principles, concepts, terminology or technical characteristics, relevant to a number of technical committees and of crucial importance to ensure the coherence of the corpus of standardization documents” (IEC, 2022)</footnote>
takes the concept of systems engineering processes managed within a life cycle framework and specifies additional requirements on those processes to achieve the intent of IEC 61508.

One result of IEC 63187 aligning with ISO/IEC/IEEE 15288 is that it offers more modularity than existing safety standards. These are often not well adapted for application in an agile environment because they tend to be aimed at a V lifecycle in a single organization. The IEC 63187 principles and the approach of integrating safety into ISO/IEC/IEEE 15288 allow use of modern systems engineering principles: complex hierarchies and agile lifecycles can be addressed by applying ISO/IEC/IEEE 15288 life cycle processes. Thus, IEC 63187 allows appropriate adaptations to an agile environment, with different lifecycles for different organizational tiers as shown in Figure 2.

<figure><img src="image_3.png" /><figcaption>Figure 2 — IEC 63187-1 recursive instantiation</figcaption></figure>

The additional process requirements given by IEC 63187 aim to ensure both that the safety objectives for the system will be achieved, and that adequate assurance information will be produced to give the acquiring organization confidence that this is so. Beyond this, IEC 63187 also provides a framework for understanding the interaction between hazards at different layers of the systems hierarchy, and specifying safety requirements on the lower layers.

IEC 63187 does not specify safety requirements for the development or realization of particular system elements. However, it puts in place a framework by which their requirements and safety objectives can be derived. IEC 61508 can still be used under IEC 63187 to realize those system elements for which it is suited. Similarly, other standards such ISO 26262² or DO-178C<fnref n="3" /> could be used, as appropriate to the application domain.

## How does IEC 63187 tackle Complex Systems?

### Recursion and iteration through the systems hierarchy

While traditional standards assume a fixed hierarchy, are intended to be applied to a complete system and have different requirements for different system elements such as hardware and software, IEC 63187 explicitly recognizes an abstract, flexible, systems hierarchy. As shown in

<footnote n="2">² ISO 26262: Road Vehicles – Functional Safety.</footnote>

<footnote n="3">³ DO-178C: Software Considerations in Airborne Systems and Equipment Certification.</footnote>
Figure 3, at each tier of the hierarchy, there is a bounded ‘system of interest’ operating within a certain environment.<fnref n="4" /> The environment is outside the scope of the engineering control for the system of interest. If aspects of the environment do need to be engineered, then a higher tier can be added to the hierarchy with those aspects included in the scope of the higher-tier system of interest. The system elements composing a system of interest can either be considered as atomic units that can be realized directly and do not need further analysis, or they could be considered as systems in their own right, and analyzed in a lower tier in the hierarchy. The system of interest forms part of the operating environment for systems in the tier below. This hierarchic approach helps manage complexity by allowing the detailed design of individual system elements to be abstracted, aiding analysis at a higher level. This approach allows systems to be considered at a high-level tier that are in the operational domain and inclusive of people, aspects of the natural environment and technological systems.

IEC 63187 is intended to be applied recursively throughout the hierarchy until the bottom tier, where more specific requirements can be set for realization of particular system elements. Depending on the systems breakdown and supply chain involved, individual participants may apply the standard at multiple tiers, or just one. This approach allows systems to be considered at differing levels of abstraction, and of aggregation of disparate physical elements. These facilitate the use of the standard from early concept stage through to in-service operation, and beyond. They also allow for the standard to be applied throughout the supply chain from a user with the need for a capability, through its acquisition agency right through to suppliers of system elements.

<figure><img src="image_4.png" /><figcaption>Figure 3 — Hierarchy of System Tiers (IEC, 2022)</figcaption></figure>

At each tier of the system, safety objectives for the system element of interest are expected to be set to allow it to satisfy safety requirements set by the tier above, as shown in Figure 4. In turn, that tier will set safety requirements to be met by the objectives of lower-tier system elements. In this way, requirements are derived for the bottom-tier system elements that can be traced back to achievement of the top-level functional safety objectives for the overall system.

<footnote n="4">⁴ In practice there can be many systems of interest at each tier, each of which may have a different ‘owner’ of that interest.</footnote>
<figure><img src="image_5.png" /><figcaption>Figure 4 — Derivation of safety objectives and requirements.</figcaption></figure>

New hazards can also be introduced at any system layer. They could result from failure modes of systems elements, deliberate implementation choices, or unintentional interactions between system elements. Such hazards may well not be present in lower-tier system elements, but only emerge through integration. IEC 63187 requires analysis to take place to reveal whether such hazards are present and further safety objectives to be set to control them. In some cases, these hazard control objectives may be discharged by setting safety requirements on lower-tier system elements. In others, this will not be feasible, and it will be necessary to iterate the requirement setting activity for the tier above. This may result in additional safety requirements being placed on other system elements, or even generate a need for a new system element to control the hazard. In this way, IEC 63187 seeks to address emergent hazards.

## Risk Model

IEC 63187 adopts the ISO/IEC/IEEE 15288 view of risk as 'the effect of uncertainty on stakeholder objectives'. It does not use the traditional measure of risk as a function of the likelihood and severity of an outcome as this is not necessarily helpful in the context of safety analysis in an abstract systems hierarchy.<fnref n="5" /> The likelihood/severity approach also does not lend itself to dynamic risk scenarios, where the probability and severity can be expected to change more frequently than the analysis can be carried out. Instead, IEC 63187 focuses on uncertainty in the control of hazards, which are defined as system states or sets of conditions that, together with a particular set of environmental conditions, will lead to harm. Hazards are 'owned' and managed at the tier of the systems hierarchy in which they are necessarily introduced, for example by the choice of a particular technology to implement a system element. Where a hazard is identified,

<footnote n="5">⁵ For example, it is not possible to assess the risk due to failure of a subsystem such as an electronic control unit (ECU) as an isolated system: it is necessary to understand the rest of the system in which the ECU operates, like a vehicle or aircraft, to understand the likelihood that failure of the ECU could propagate to a hazardous state in the top-level system. Further information is needed about the operating environment to understand the likelihood that an accident might result, and the severity of the harm caused. Such an analysis may be feasible in relatively simple systems using techniques such as Failure Modes and Effects Criticality Analysis (FMECA), but it is not feasible in more complex systems, where system elements are being independently developed and information about the higher system tiers is not available.</footnote>
safety objectives are set to control the impact of this hazard and prevent it resulting in harm or loss. Requirements are then set and allocated to system elements to ensure that the safety objective is met. This approach lends itself to application of control theory and systems engineering-based techniques such as System-Theoretic Process Analysis (STPA) (Leveson & Thomas, 2018).

Aside from being used to judge the tolerability of potential accidents, traditional standards use the likelihood/severity risk metric to define the level of rigor required in designing particular parts of a system, or the level of confidence required that particular requirements have been achieved. As IEC 63187 does not use this risk metric, it has to propose an alternative method to determine where effort should be prioritized to control hazards and provide assurance. To do this, it introduces the concept of a ‘measure of importance’.

## Measures of Importance

In simple terms, the IEC 63187 concept of a ‘Measure of Importance’ (MOI) describes how much we care about getting right part of the safety architecture or its implementation. It plays a similar role to concepts like Safety Integrity Levels (SILs) or Design Assurance Levels (DALs) in other standards, but rather than directly defining the level of rigor to be applied in different systems engineering processes or the degree of confidence required when assuring safety, it provides a means of flowing this level of importance or concern down through layers of design. The MOI concept is flexibly defined, to enable it to be recursively applied at different system layers and indeed, to supply chains with different numbers of layers. Although IEC 63187 provides an example in an informative annex, it does not define a specific MOI schema, but requires one to be drawn up as part of the safety acceptance strategy and agreed between the acquirer and supplier. This allows the concept to be tailored to align to national legislation or regulatory requirements, and to reflect particular concerns of the acquirer. For instance, the schema can prioritize harm to humans as more important than financial loss, seek extra rigor for particular hazards that cause societal concern (e.g. radiological hazards), or require extra scrutiny for particular technologies.

Measures of Importance can be applied to hazards, safety objectives and requirements, potentially with different scales for each. The MOI for a hazard will be based on the severity of the associated loss, conditioned by factors such as the organization’s risk appetite in different operational contexts (e.g. training vs. military operations). While likelihood of the loss would not be taken into account directly, the degree of contribution of the hazard to the loss could also be a conditioning factor. Hazard MOIs are used to set MOIs for associated safety objectives, which in turn are used to set MOIs for their supporting safety requirements, again with conditioning factors taken into account, such as the degree of contribution of a safety objective to the overall safety architecture (Figure 5). These conditioning factors allow the MOI schema to reflect the overall safety strategy for the system, trade-offs between safety, capability and other concerns, and the importance of different system elements to the overall architecture. The allocation of MOIs to safety requirements means that there will be a flow down to lower-level system tiers. IEC 63187 does not define a particular set of conditioning factors, but allows the organisation using the standard to define them as part of their MOI schema. This means a translation may be necessary, as different tiers may use different MOI schemas. At the bottom system layer, there will also need to be a translation from the MOI schema to measures specific to the chosen implementation standards, such as SILs or DALs.
<figure><img src="image_6.png" /><figcaption>Figure 5 — MOI overall schema</figcaption></figure>

MOIs are a powerful and flexible concept, but have the potential to be confusing to use in practice. If MOI schemas are not set up appropriately, then application of IEC 63187 may not result in the acquirer gaining the assurance of safety that they desire. This should not be an insurmountable challenge. Acquirers already have to set their expectations for the level of assurance provided by their supply chain, but IEC 63187 makes the requirement more explicit. However, the success of the standard in this respect may well rest on the strength of the guidance available to help implementers to define practical MOI schemas.

## Relationship to National Defense Standards

As an international standard, IEC 63187 needs to be capable of application in any country. It must be independent of requirements from particular legislative or regulatory jurisdictions or acquisition regimes, so will not reference particular national defense standards. It will also not necessarily align directly with the vocabulary in use in different countries, since this varies and common terms like ‘hazard’ can be interpreted differently, even in countries that share the English language (McDermid, 2007). Instead, it will build on the common vocabulary used in other IEC and International Organization for Standardization (ISO) standards. However, development of IEC 63187 has been informed by knowledge of various national defense standards and the thinking behind them.

IEC 63187 aligns directly with the stated objective of the US Department of Defense to “integrate risk management into the overall systems engineering process” (DoD, 2012). Using the standard is likely to help satisfy the requirements of Mil-Std-882E Clause 4.3 to document how this is achieved, and to identify applicable requirements for realisable system elements. IEC 63187 should also provide a methodology to satisfy Mil-Std-882E Task 209 – System of Systems Hazard Analysis. Similarly, use of IEC 63187 aligns with the British policy to prefer open international standards over its own Defence Standards (MOD, 2022). The UK Ministry of Defence encourages suppliers to use the recognised good practice provided by such standards to demonstrate compliance with the requirements of its main safety management standards, Def Stan 00-055 and Def Stan 00-056. NATO also has a policy of adopting suitable non-NATO standards, civil or otherwise, “to the maximum extent.” (NATO, 2022).

IEC 63187 does not define precise formats or acceptance criteria for deliverables, but requires the acquirer and supplier to agree a safety acceptance strategy. This approach allows the flexibility for the organization procuring equipment to specify nation-specific assurance requirements such
as the US risk acceptance requirements in DoDI 5000.88, or the explicit safety argument required by the UK MOD. This is intended to allow IEC 63187 to remain compatible with the US Mil-Std-882E, the UK's Def Stan 00-055 and other nations' safety management standards. It can also support the philosophy that only the person accountable for operating a system safely is positioned to make claims about the overall safety of the deployed system, taking into account the operational environment and other lines of development, such as training or doctrine. In this context, the information provided through application of IEC 63187 does not provide the overall safety case itself, but supports the overall safety case made by the accountable person, when combined with arguments from other areas of their safety management system.

IEC 63187 has a broad scope that encompasses system safety and functional safety. While it does not exclude intrinsic hazards, it focuses less on hazards related to “what the system is” than “what the system does”. This is because such issues around functionality and behavior can be addressed at a conceptual level in the systems engineering domain, while implementation details like manual handling or use of hazardous materials are already well covered by realization standards for individual system elements. This means that IEC 63187 is likely to need to be used alongside existing standards to cover the complete scope of Mil-Std-882E or Def Stan 00-056. And for some less complex systems, it may be more appropriate to continue using implementation standards such as IEC 61508 directly.

Although defense ministries are likely to use IEC 63187 in their contracts with defense suppliers, it could also be applied at a higher level, to help understand and manage the emergent interactions between the systems being procured, or as part of studying the end user's needs and selecting suitable new procurement items to fit alongside existing systems to deliver the required capability.

## Development Progress

IEC 63187 is being developed under IEC Technical Committee TC65 (Industrial-process measurement, control and automation), by Subcommittee SC65A – Systems Aspects, the same part of the IEC that maintains IEC 61508. The Working Group drafting IEC 63187 (IEC SC65A WG18) has been meeting since 2018 and currently includes representatives from ten nations. It is drafting the standard in two parts. IEC 63187-1 will contain the normative parts of the international standard, along with informative material including an annex on the concepts and rationale of the standard. Further guidance will be provided in IEC TR 63187-2.

At the time of writing, WG18 is updating the draft of IEC 63187-1 to address the comments received following its circulation as a Committee Draft (CD) late in 2022. It is planned to be circulated as a CD for an approval vote (CDV) in early 2024. Assuming that the CDV is approved but further technical comments are made, it is likely to be issued as a Final Draft International Standard (FDIS) in late 2024 and eventually published in 2025.

Drafting has started on the supporting guidance in IEC TR 63187-2. This part of the standard will have Technical Report status rather than a being full International Standard, meaning it is purely informative, rather than setting normative requirements. Technical Reports have a more flexible approval route, meaning that there is scope to shape the Part 2 guidance to address comments raised against Part 1 of the standard, and still publish both parts at the same time.
Disclaimer

Views expressed in this paper are those of the authors and not necessarily those of the International Electrotechnical Commission or the authors' organizations.

References

DoD. (2012). Mil-Std-882E: Standard Practice - System Safety. Department of Defense.

Henshaw, M., Dahmann, J., & Lawson, B. (2022). Systems of Systems (SoS). In S. E. Board, *The Guide to the Systems Engineering Body of Knowledge (SEBoK)*, v. 2.7. Retrieved May 23, 2023, from https://sebokwiki.org/wiki/Systems_of_Systems_(SoS)

IEC. (2010). IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems.

IEC. (2022). Horizontal Standards. *Horizontal Standards*. Retrieved October 2, 2022, from https://www.iec.ch/news-resources/horizontal-standards

IEC. (2022). *IEC 63187-1: Functional safety – Part 1: Framework for safety critical E/E/PE systems for defence industry applications*. IEC Committee Draft.

Inge, J., & Williams, P. (2023, February). IEC 63187-Tackling complexity in defence systems to ensure safety. In M. Parsons (Ed.), *The Future of Safe Systems: Proceedings of the Safety-Critical Systems Symposium*, (pp. 233–245). York. Retrieved from https://scsc.uk/scsc-179

ISO. (2015). ISO/IEC/IEEE 15288: System and Software Engineering – System life cycle processes.

Leveson, N. G., & Thomas, J. P. (2018, March). *STPA Handbook*. Boston, MA: Massachusetts Institute of Technology. Retrieved from https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf

McDermid, J. A. (2007). Comparison of MilStd 882E and Interim Defence Standard 00-56 Issue 3. In A. G. Boyer, & N. J. Gauthier (Ed.), *Proceedings of the 25th International System Safety Conference*, (pp. 509–518). Baltimore.

MOD. (2022). *JSP 920: MOD Standardization Management Policy – Part 1: Directive*. Joint Service Publication, Ministry of Defence. Retrieved from https://www.dstan.mod.uk/policy/JSP920_Part1.pdf

NATO. (2022). AAP3: Directive for the Production, Maintenance and Management of NATO Standardization Documents. *Edition K Version 2*. NATO Standardization Office.

Ricque, B., Joguet, B., Brindejonc, V., Semeneri, N., & Potiron, K. (2022, October). IEC 63187: intégrer la sûreté de fonctionnement au sein de l'ingénierie système. *Congrès Lambda Mu 23 "Innovations et maîtrise des risques pour un avenir durable"*. Paris. Retrieved from https://hal.science/hal-03878071/