Section 4 What to expect from the NS Software Rules

4.1 Structure of the NS Software Rules

The NS Software Rules are goal-based and are expressed using the standard LR approach of giving the Goal, the Functional Objective, Performance Requirements, and Verification Requirements, each presented in their own Section. LR’s approach is derived from and compatible with ANEP‑77. In this case, these Sections are preceded by general requirements and a Section providing the Context of the NS Software Rules. The detail of the NS Software Rules structure is given in Table 1.4.1 Structure of NS Software Rules together with a short description of what each Section provides.

Table 1.4.1 Structure of NS Software Rules

Rule	Summary description Section content
Ch 1, 1 General Requirements	Definitions
Ch 1, 2 Context	Focuses on the relationship of the NS Software Rules to the system and Engineering System level activities. As illustrated in Figure 1.3.1 NS Software Rules Overview Process Diagram, this is an important relationship because the activities specified at the system and Engineering System levels are essential for the successful Production of Software in compliance with these NS Software Rules.
Ch 1, 3 Goal	‘The use of software as an implementation technology for an Engineering System is not to compromise the satisfaction of the Rules applicable to that Engineering System.’
Ch 1, 4 Functional Objective	’To manage: (a) the realisation of all Relevant Hazard Requirements; and (b) the risk arising from the use of software as an implementation technology for Engineering Systems.’, where Relevant Hazard Requirement is a defined term, see Ch 1, 5 Abbreviations and Definitions.
Ch 1, 5 Performance Requirements	This Section is comprised of four main sub-Sections: General requirements for the Production of Software (Ch 1, 5.1 General requirements for the production of software): Hazard Requirements to be provided to the Producer of Software; Producer of Software to consider the effect of Software failure; Producer of Software to communicate any adverse effect up the supply chain; Where necessary, define additional Relevant Hazard Requirements. Specifics for Production of Software (Ch 1, 5.2 Production of software): The NS Software Rules applicable to the production of any Software Development Status (New, Modified, Existing) Specifics for Software of Modified (Ch 1, 5.3 Modified software) and Existing (Ch 1, 5.4 Existing software) Software Development Status: Defines the subset of applicable NS Software Rules and, for Software of a Modified status, the requirement to assess the impact of the modification on previously developed Software Products.
Ch 1, 6 Verification Requirements	This Section generally follows the structure of Ch 1, 5 Performance Requirements but gives the process and evidence requirements that would enable a Producer of Software to meet the performance requirements in the way most acceptable to LR. It elaborates some specific approaches for dealing with the Software of an Existing Software Development Status. It defines documentation requirements and summarises what documentation is required to meet the NS Software Rules.

4.2 Underlying and Guiding Principles

The key principle that has driven the development of the NS Software Rules has been to not specify specific processes, methods, procedures, techniques or other requirements that could constrain innovation, or force the use of Software Production approaches that do not suit, or are unfamiliar to, a Producer of Software.

To enable LR to continue to assess systems effectively within this goal-based approach, the NS Software Rules include requirements for:

the Relevant Hazard Requirements to be derived using a risk-based approach as determined by considerations of the requirements of IEC/ISO 31010;
for the Producer of Software to consider the effect of Software failure;
for a suitable international or national standard to be selected and its applicability justified by the Producer of Software, agreed with LR, and applied to the Production of Software (Software Production Standard);
for Software to be produced using a quality management system that satisfies the requirements of ISO 9001 as guided by ISO/IEC 90003, and for configuration management satisfying the requirements of ISO 10007 to be used;
for a plan for the Production of Software to be developed that incorporates the requirements of the Software Production Standard, and for it to be used for the Production of Software; and
for the Producer of Software to produce a documented Argument that provides a compelling and comprehensible demonstration that the functional objective has been met. This Argument is to be supported by evidence.

Another underpinning feature of the NS Software Rules is the definition Relevant Hazard Requirements:

‘Software requirements which cover how the software mitigates a Relevant Hazard Cause including, but not limited to:

(a) specific functional behaviour to mitigate Relevant Hazard Causes, fault indications, accuracy and response times;

(b) what it [the software] must not do; and

The requirement of item (c) of this definition may be implemented as Safety Integrity Level, a Design Assurance Level, or some other predefined level of the chosen Software Production Standard. Irrespective of how the degree of reliance is implemented, it is necessary for the processes, methods, and techniques used for the production of the Software to provide assurance that the Software can be relied on to the degree necessary to allow the Relevant Hazard Requirement to deliver the expected risk mitigation.

There is also an explicit requirement for the Producer of Software to communicate and co-operate with LR to enable it to plan its assessment activities based on criteria, such as the risk related to identified Relevant Hazards, the demonstrable capability and experience of the Producer of Software, and the Software Development Status, among others.

Because the new approach allows the Producer of Software flexibility in the choice of standards applied and the details of the Software Production lifecycle processes, there is a need for communication with, and information to be provided to, LR at an early stage. This will ensure that the risk that LR might not be able to accept the Software is managed at an early stage of, and throughout, a project. In particular, it is imperative that a proposal for how the ‘Argument that the functional objective has been met’ (see Ch 1, 5.2 Production of software 5.2.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020) is discussed with LR as soon as is practical. This is because it is likely that, if the Argument is rejected at the later stages of the Production of Software, it will not be possible for the Producer of Software to obtain the necessary supporting evidence in a cost-effective or timely way.

4.3 Production of Software

The term Production of Software has been chosen very specifically and has been defined carefully to ensure the NS Software Rules are applied to the full range of Software-based systems which should be within the scope of LR’s Rules.

Specifically, Production of Software is defined as:

‘The process of interpreting requirements and realising those requirements as a Software Product by using suitable software lifecycle steps and applying the requirements of quality, safety and other management systems. Production of Software includes all lifecycle phases from requirements (including Relevant Hazard Requirements) to support for system integration and system testing. Where iterative or cyclical lifecycles are used, the Production of Software includes all iterations or cycles. The Production of Software includes tailored lifecycle phases where Existing or Modified Software is used.’

For most types of Software, the applicability of the requirements of the NS Software Rules should be easily understood. However, there are situations, such as when using Commercial-Off-The-Shelf Software (COTS) products, or building a software-based solution from components that do not themselves require any re-compiling, where it may not be obvious that the NS Software Rules apply. However, even though there may be no program code adjustment or re-compiling, it does not mean that Production of Software, as defined by the NS Software Rules, is not occurring. Specifically, Software implementing Relevant Hazard Requirements in any Engineering System covered by the LR Naval Rules, falls under the NS Software Rules and is deemed to have some form of Production of Software, albeit with a simplified Software Production lifecycle.

In these situations, normal quality and configuration management systems practices are to be applied together with the activities of a suitably tailored lifecycle that include at least:

requirements capture and management;
confirmation of the adequacy of the features and performance of the Software Product to meet the requirements;
the configuration / parameterisation / or other steps taken to tailor the Software for the specific application;
verification, testing, and validation activities to confirm and demonstrate that the requirements, including the Relevant Hazard Requirements, have been met, and that foreseeable failure modes do not exist or are adequately managed;
support for Engineering System testing; and
build and distribution of the Software Product.

Irrespective of the scale or complexity of the Production of Software, or the development status of the Software Product the requirements of the NS Software Rules apply. The ‘Argument that the functional objective has been met’ (See Ch 1, 5.2 Production of software 5.2.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020) needs to be provided in all cases, as do the Justifications for the Software Production Standard and deviations from it, and the Software Development Status claimed.

4.4 Requirements for Producers of Software

This sub-Section is primarily developed from the Performance Requirements stated in the NS Software Rules. As discussed in Table 1.4.1 Structure of NS Software Rules, the Verification Requirements follow the structure of the Performance Requirements, and provide additional requirements that will enable Producers of Software to meet the performance requirements in the way most acceptable to LR. Ch 1, 4.4 Requirements for Producers of Software 4.4.11 of the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 additionally discusses the Arguments that could be used for Software of an Existing development status.

4.4.1 Who is the Producer of Software

One issue arising from the discussion of the use of Software with an Existing Software Development Status, is that there is sometimes ambiguity about who is the Producer of Software. In many cases, especially when Software is bought from a catalogue, or is a standard product with no customisation by the original developers or any of the other organisations in the supply chain, the role of the Producer of Software sits with the Engineering System supplier. In this role, the Engineering System supplier has responsibility for meeting the requirements of the NS Software Rules, see Ch 1, 4.3 Production of Software of the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 for discussion of particular issues for Software of an Existing Software Development Status.

If an organisation other than the Engineering System supplier is taking responsibility for configuring a Software Product with an Existing Software Development Status for use in its final application, that organisation is to assume the role of Producer of Software.

The remainder of this Section discusses some of the more important aspects of the performance requirements specified in the NS Software Rules.

4.4.2 Analysis to determine how the Software could affect the Relevant Hazards and where necessary agree new Relevant Hazard Requirements see

Ch 1, 5.1 General requirements for the production of Software 5.1.3 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020

Ch 1, 5.1 General requirements for the production of Software 5.1.3 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 states: ‘It is to be determined whether and how the failure or unspecified behaviour (see NOTE 1) of the software could credibly result in: (a) an event that escalates to a Relevant Hazard; (b) impairment of the mitigation of a Relevant Hazard; or (c) impairment of recovery from a Relevant Hazard.’

and

‘Note 1. Failure means that the software does not perform its function at all. Unspecified behaviour means the software performs its function partially or incorrectly.’

It is expected that this analysis would be done at the physical system level and will identify potential functional failures and their effects using a technique such as Functional Failure Analysis. The requirement is solely related to the assessment of Relevant Hazard Causes from the Software.

It is unlikely that this analysis can be done without input from at least the Engineering System level because of the need to understand the effect of failure for situations (b) and (c) of the Requirement. Once the analysis has been performed, related NS Software Rules require that the results are communicated up the supply chain and, where an alternative design cannot remove the Software from potentially causing one of the outcomes of (a), (b), or (c), additional Relevant Hazard Requirements are to be specified for the Software so that the necessary mitigation is achieved. The derivation of the additional Relevant Hazard Requirements must be performed with the same rigour used for all other Relevant Hazard Requirements, see Ch 1, 4.2 Key Principle.

4.4.3 It is to be demonstrated that the Relevant Hazard Requirements have been met (Ch 1, 5.2 Production of software 5.2.1 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

There are two issues that must be addressed:

that the functional part of the Relevant Hazard Requirements has been achieved, that is what has to be done, and what has not to be done, by the Software; and
that the reliance placed on the Software to deliver its function has been achieved.

The first issue is often demonstrated through testing, possibly combined with analysis and or simulation. The second issue is demonstrated through the use of product and process features appropriate to the level of reliance being placed on the Software, and as required by the agreed Software Production Standard. Product features include the use of such techniques as the error detecting codes in communications or run-time range checking of input signals within the design and implementation. In all instances, the product features should include defined and controlled handling of the errors detected. The process features are the use of appropriate quality management system processes, methods and procedures for the Production of Software.

The purpose of making the requirement to demonstrate that the Relevant Hazard Requirements have been met explicit is to ensure that the necessary evidence is produced during the Production of Software to enable both attributes of Relevant Hazard Requirements to be demonstrated, it not being practicable to retrospective derive the process and product features.

Ch 1, 5.2 Production of software 5.2.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 refers to the Argument being supported by a body of evidence. The satisfaction of this requirement (Ch 1, 5.2 Production of software 5.2.1 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020) naturally provides some of the evidence for the Argument. See also the discussion on evidence type in Ch 1, 4.4 Requirements for Producers of Software 4.4.4.

4.4.4 Make an Argument for the Software meeting the functional objective (Ch 1, 5.2 Production of software 5.2.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

This Rule states: ‘An Argument, supported by a body of evidence, that provides a compelling, comprehensible and valid demonstration that the functional objective identified in Ch 1, 4 Functional Objective has been met, is to be made and documented.’; the functional objective being identified in Figure 1.3.1 NS Software Rules Overview Process Diagram of this document.

This Rule requires the Producer of Software to consider how it can be assured the Production of Software will lead to the satisfaction of the functional objective. Part of the consideration is how this necessary assurance can be communicated and demonstrated to the parties wishing to use the Software. The Argument required by this requirement can be considered as the communication and demonstration that the necessary assurance has been used in the Production of Software. Figure 1.8.1 GSN Generic Argument Example (part 1) to Figure 1.8.4 GSN Generic Argument Example (part 4) provide illustrations of typical Arguments for some representative types of Software.

It can be seen from the preceding discussion about an Argument, that the production of the Argument needs to be planned from the earliest stages of the Production of Software, because the way in which Production of Software is undertaken will be influenced by the way it is intended to make the Argument. It is recommended that Producers of Software develop an outline Argument prior to the Production of Software, updating the Argument with evidence references as the Production of Software progresses.

An important point to remember regarding this requirement is that the Argument is to be supported by evidence; the evidence is not the Argument. It is not acceptable for the evidence to be presented without the Argument; it is for the Producer of Software to demonstrate through the Argument that the functional objective has been satisfied using the evidence to substantiate the claim being made in the Argument.

Two Types of Evidence

There are two types of evidence:

The first type is evidence that confirms factual part of the Argument; for instance, that functional testing has demonstrated that all the functional requirements of the Software have been tested.
The second type is evidence that gives confidence in the value of the first; for instance, the functional testing evidence would be of no value if the competence of the test designer was inadequate or the version of the Software tested could not be assured.

The generation of these two types of evidence should be taken into account when addressing Ch 1, 5.2 Production of software 5.2.1 in theProvisional Rules and Regulations for Software to be used in Naval Ships, January 2020, see , Ch 1, 4.4 Requirements for Producers of Software 4.4.3above.

4.4.5 Follow good quality management system practices – compliance to ISO 9001 and ISO 10007 (Ch 1, 5.2 Production of software 5.2.3 and 5.2.4 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

Underpinning the international standards related to the Production of Software is a presumption, if not a specific requirement, that a good quality management system will be used for the Production of Software.

ISO 9001 interpreted using the guidance of ISO/IEC 90003 has been selected as a representative standard for a good quality management system for the NS Software Rules. The NS Software Rules do not require that a Producer of Software has a certificate of compliance to ISO 9001, however, they do require that the requirements of the standard can be satisfied. It is recognised that some organisations will have developed Software Quality Processes based on, or aligned to, other standards, such as EFQM Excellence Model, or one of the capability maturity models used for Software. In these cases, it is expected that a demonstration that the requirements of ISO 9001 have been satisfied will be relatively easily achieved.

The NS Software Rules require configuration management to be used for the Production of Software, and they use ISO 10007 as the reference source of the minimum standard necessary. A Producer of Software will be expected to demonstrate the equivalence of its configuration management systems to the requirements of ISO 10007.

4.4.6 Identify, justify, and apply an agreed international standard for the Production of Software (Software Production Standard) (Ch 1, 5.2 Production of software 5.2.5, 5.2.6, and 5.2.12 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

The NS Software Rules deliberately do not specify a specific standard for the Production of Software, instead, they require that an international or national standard, suitable for the Production of Software at the level of reliance placed on it by the Relevant Hazard Requirements, is agreed with LR (once agreed, the standard is referred to as the Software Production Standard). This flexibility is intended to provide a Producer of Software with the ability to use a standard with which it is familiar. The NS Software Rules require a Justification to be produced for the use of the Software Production Standard selected. This is seen as part of the process for reaching agreement with LR, because LR will need to be convinced that:

the standard provides suitable controls for the level of reliance being placed upon the Software to deliver the Relevant Hazard Requirements;
the standard is suitable for the implementation technologies being used (i.e. what might be suitable for ladder logic being implemented on a PLC may not be suitable for a general-purpose computer using general purpose programming language, or vice versa); and
the Producer of Software has sufficient experience and understanding of the standard to be able to meet its requirements.

Once the Software Production Standard has been agreed with LR, the Producer of Software is required to use processes, methods, procedures, and techniques that implement the requirements of the standard.

4.4.7 Plan and implement the Production of Software taking into account the requirement of the Software Production Standard for the reliance being placed on the Software (Ch 1, 5.2 Production of software 5.2.7, Ch 1, 5.2 Production of software 5.2.8, Ch 1, 5.2 Production of software 5.2.9 and Ch 1, 5.2 Production of software 5.2.11 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

This is an important activity because the plan forms the basis of the Production of Software. The plan should ensure that:

the requirements of the Software Production Standard are realised in the Production of Software; and
evidence is produced during the Production of Software to:
- demonstrate that the Relevant Hazard Requirements have been met; and
- support the Argument that the functional objective has been met.

It is recognised that the plan for the Production of Software might develop to include more detail of specific lifecycle activities as the project progresses. However, an outline of all Production of Software activities should be given from the first issue of the plan; and the plan should be complete and approved for any lifecycle stage before that lifecycle stage is started.

Ch 1, 5.2 Production of software 5.2.9 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 identifies specific content that should be included or taken account of in the plan for the Production of Software. The emphasis being made by this requirement is that the plan should be for the Production of Software of the specific Software Product and not a generic plan; although it is recognised that a generic plan might be a starting point for the specific plan.

The plan for the Production of Software is to be submitted to LR to enable comments on the adequacy of the plan to be taken into account by the Producer of Software before there is a need to implement the provisions of the plan.

The plan is important to LR because LR will establish its assessment activities taking into account the activities specified in the plan by the Producer of Software.

4.4.8 Agree Software Development Status (Ch 1, 5.2 Production of software 5.2.10 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

The plan for the Production of Software is to justify and record the Software Development Status as New, Modified, or Existing. The Justification should clearly demonstrate the rationale for the assigned status. Specific criteria, that are to be used when considering assigning Software a Modified status, are specified by Ch 1, 5.2 Production of software 5.2.9 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020. These criteria are specified because the Modified status is considered the most difficult status to judge.

LR will use the Justification made in the plan for the Production of Software as the formal basis of its agreement on a Software Development Status. However, it is recognised that in some instances, particularly when assigning the Modified status, and possibly the Existing status, some discussion between LR and the Producer of Software on the subject may be required to reach an agreement on the status assigned.

4.4.9 Produce Software in accordance with the Plan for the Production of Software (Ch 1, 5.2 Production of software 5.2.13 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

The preparatory work discussed so far in this document should lead to the formulation of a plan for the Production of Software that:

will deliver Software that can demonstrably satisfy the Relevant Hazard Requirements;
will produce the Argument that shows the functional objective has been met and delivers the necessary evidence to support the Argument;
is based on an appropriate Software Production Standard; and
meets the requirements of the NS Software Rules.

It is therefore imperative that the Production of Software is performed in accordance with the plan. Refer to Ch 1, 4.4 Requirements for Producers of Software 4.4.4 for a discussion on how the incremental production of the ‘Argument that the functional objective has been met’ can be used to demonstrate that the Production of Software has been performed in accordance with the plan.

4.4.10 Software of Modified Software Development Status (Ch1, 5.3 Modified software in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020).

Two performance requirements have been included in the NS Software Rules for the Software of a Modified Software Development Status. The first is that the Software modification is performed using the processes defined by the Producer of Software’s quality management system. The second specifically requires the impact of the modification on previously developed Software to be assessed and that the results of that assessment be used to tailor the elements of the quality management system used for the Production of Software. In practice, the second requirement will result in the plan for the Production of Software being properly tailored to the needs of the modification.

Often, when modifications are made to a pre-existing Software Product, it is found that despite an initial assessment of the impact of the change, other interactions in the Software are found during the development that were not identified in the initial assessment, and that are affected by the modification. To cover this eventuality, Ch 1, 5.3 Modified software 5.3.3 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 specifies that the impact assessment is repeated during the development. It is expected that the need for re‑assessments would be driven by matters arising during the Production of Software, and that the methods of re‑assessment would be appropriate to the particular circumstances. Evidence of re-assessments, the criteria for re-assessment, and the correct application of these criteria will need to be retained and made available to LR.

The application of the NS Software Rules for Software of a Modified status is primarily for the parts of the Software that are being changed, however, the Argument that the functional objective has been met needs to be at a Software Product level, which will necessarily include the Software that is unchanged. This may lead to the need for performance data or Production of Software evidence for the original product to be provided to support the Argument being made. In these circumstances, it is important to engage in communication with LR at an early stage to ensure that the proposed approach to making the Argument is acceptable to LR. This is because it is possible that additional assurance activities would need to be undertaken for the Producer of Software to be able to make a compelling Argument about the Modified product, or in extreme cases, the proposed Software Product would not be suitable for use and an alternative, acceptable to LR, would need to be selected.

4.4.11 Software of Existing Software Development Status (Ch 1, 5.4 Existing software in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

Two performance requirements have been included in the NS Software Rules for Software of an Existing Software Development Status. The first is to define the extent of the requirements applicable to Existing Software, it being the case that, by definition, there is no detailed Software design or coding to be undertaken for Existing Software. Ch 1, 4.3 Production of Software discusses the Production of Software requirements, which include those for Existing Software in more detail. The second is the requirement to specify additional Relevant Hazard Requirements if it is found that the Software could affect the Relevant Hazard and that the Relevant Hazard Cause cannot be removed at the Engineering System or higher level. For Software of an Existing Software Development Status, changes to the Software are not to be undertaken; therefore, the implementation of any additional Relevant Hazard Requirement would need to be through configuration of the Existing Software or by providing an additional Software Product to work in co-operation with the Existing Software.

When the Producer of Software wishes LR to accept Software based on earlier evidence of its suitability, the following requirements apply:

Ch 1, 6.5 Software previously assessed and certified in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 is applicable to Software that has been previously assessed and certified and where the Argument for the suitability of the Software relies on the previous certification.
Ch 1, 6.6 Software previously used and trusted with development data available in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 is applicable to Software that has been previously used and trusted with development data available, and the Argument for suitability of the Software relies on the development data.
Ch 1, 6.7 Software previously used and trusted with previous-use data available in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 is applicable to Software that has been previously used and trusted with previous-use data available, and the Argument for suitability of the Software relies on the previous-use data.

While the specific requirements differ depending on which Argument is being used, an underlying requirement is that, for the pre-existing evidence related to Software of an Existing development status to be valid, it must be related to the specific Software Product being used and the context of use of the previous and proposed application must be the same or equivalent.

4.4.12 Other considerations

The nature of complex projects often leads to variations in requirements and changes to plans as the practicability of solutions are realised at the Software, Engineering System, ship systems, and operator levels. When changes are needed that impact on any of the agreements reached with LR, LR is to be informed by the Producer of Software at the earliest reasonably practicable stage so that new agreements can be reached. Requirements to this effect are included at various points in the NS Software Rules.

4.5 How LR will conduct the approval and its interaction with supply chain parties

In this Section, the focus is on the way LR performs its assessment and what that means for interaction with the organisation producing the systems or equipment that are subject to the provisions of the NS Software Rules.

The role of LR is to assess the implementation of the NS Software Rules.

In respect of the NS Software Rules,there is a need for early engagement between the Producer of Software and LR. This early engagement is necessary because the NS Software Rules are goal-based, which allows a flexibility in the way the NS Software Rules are satisfied, and it will help ensure that the approach chosen by the Producer of Software is capable of meeting the NS Software Rules, and is acceptable to LR.

In particular, early communication allows agreement on a number of choices that need to be made by the Producer of Software, that, if left to a later stage, could lead to difficulty in achieving Classification and / or wasted effort and additional work.

The following sub-Section outlines the main activities for LR.

4.5.1 Agreement to be reached with the Producer of Software

There are a number of agreements that need to be reached with LR:

System integrators are required to perform certain activities as specified in the NS Software Rules. Ch1, 2.1 Context 2.1.7 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 specifies agreeing the derogations of the NS Software Rules based on the reduced scope of the system integrator’s activities in respect to Software.
Ch 1, 5.2 Production of software 5.2.6 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 specifies that the Justification for the chosen Software Production Standard must be submitted to LR for its consideration. In practice, if LR did not accept the Justification for the Software Production Standard a further discussion and submissions would be necessary until a Justification acceptable to LR was provided.
Ch 1, 6.9 Documentation required for design review 6.9.1 (c) in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 specifies that the Argument required by Ch 1, 6.1 General requirements for the production of software 6.1.3 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 be provided for design review. This is a key document to be produced by the Producer of Software. It effectively presents the Argument for why the Software should be considered suitable for use. If LR is not convinced by the Argument, cannot verify that evidence supports the Argument, or does not have confidence in the way the evidence has been produced, the Software will not receive LR approval, see also Ch 1, 4.5 How LR will conduct the approval and its interaction with supply chain parties 4.5.3.
Ch 1, 5.2 Production of software 5.2.10 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 is in respect of agreement on the Software Development Status.
This is important because the specific requirements of the NS Software Rules that apply to the Production of Software will be dependent on the Software Development Status of the Software. For example, all Rule requirements apply to Software of a ‘New’ development status, whereas Software of an Existing development status would not have the requirement applied that directly related to the production of code; that is Software design, coding and testing of the code at a level lower than a complete Software Product.
Ch 1, 6.1 General requirements for the production of software 6.1.5 and 6.1.6 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 are related to agreeing with the Producer of Software when the analysis of the effect of the Software on the Relevant Hazard will be undertaken and the criteria that would lead to re-evaluation of the analysis. The initial analysis is to be performed prior to the end of the requirements capture stage of production.
For Software of a Modified development status, it is specified in Ch 1, 6.3 Modified software 6.3.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 that agreement is to be reached with LR on the criteria for when the Producer of Software should repeat impact analysis.
For Software of an Existing development status, it is specified in Ch 1, 6.4 Existing software 6.4.4 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020 that agreement is to be reached with LR on the additional assurance necessary when the existing Argument does not adequately demonstrate satisfaction of the Relevant Hazard Requirements.
In respect of documentation, agreement is to be reached on:
- computer-based tools to read documentation ;
- which formally released versions of documents to deliver to LR;
- the strategy and basis for the incremental production of the Argument; and
- specific documentation to meet the NS Software Rules. (

Note:

See Ch 1, 6.8 Documentation required for design review in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020, paragraphs 6.8.2, 6.8.3, 6.8.6 and 6.8.7)

4.5.2 Establish the scope of approval (Ch1, 2.1 Context 2.1.6 and 2.1.7 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

Deciding on what is to be considered a Software Product is difficult because of the way a particular Software Product can comprise or be dependent on multiple other Software Products. For instance, notionally self-contained products can be comprised of an operating system (be it general purpose, like Microsoft Windows or Linux, or a specialist real-time runtime environment, like VxWorks) that is provided by a third party; generic core functionality that is subject to a product lifecycle different than that of the project specific application software; and various third party products or libraries such as communications drivers, database and related management functionality, graphics libraries, data loggers, report generators, etc.

In the situation where a Software Product is dependent on other productions, agreeing what constitutes the Software Product and who is the Producer of Software is not easy. It requires appropriate attention to ensure that the NS Software Rules are applied to the correct products and by the correct parties.

4.5.3 Plan the assessment (Ch1, 6.2 Production of software 6.2.12 and 6.2.13, Ch1, 6.5 Software previously assessed and certified 6.5.2, and Ch 1, 6.6 Software previously used and trusted with development data available 6.6.3 and Ch 1, 6.6 Software previously used and trusted with development data available 6.6.4 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020)

As mentioned in Ch 1, 4.2 Underlying and Guiding Principles LR bases part of its assessment activities on the specific characteristics of the Software Product and the Producer of Software, such as the risk related to identified Relevant Hazards, the demonstrable capability and experience of the Producer of Software, and the Software Development Status, amongst other criteria.

Underlying LR’s assessment approach will be the use of proven tools and techniques such as:

Document review;
Capability review / audit;
Compliance audits (with: quality management system arrangements and or Software Production Standard);
Witnessing tests; and
Alternative / additional technical review or analysis.

The NS Software Rules identify certain documentation to be provided to allow LR’s assessment to take place, and importantly, they also require co-operation from the Producer of Software so that LR can formulate and implement an effective and efficient assessment strategy. This leads to the need for good communication between LR and the Producer of Software, based on the Production of Software programme / schedule, to enable LR’s assessment planning to be coordinated with activities being undertaken for the Production of Software.

Key points within the NS Software Rules which must be communicated to and coordinated with LR are indicated by some of the section heading in this document as shown below:

Ch 1, 4.4 Requirements for Producers of Software 4.4.2, ‘Analysis to determine how the Software could affect the Relevant Hazards (see Ch 1, 5.1 General requirements for the production of Software 5.1.3 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020’;
Ch 1, 4.4 Requirements for Producers of Software 4.4.4, ‘Make an Argument for the Software meeting the functional objective (Ch 1, 5.2 Production of software 5.2.2 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020’;
Ch 1, 4.4 Requirements for Producers of Software 4.4.6, ‘Identify, justify, and apply an agreed international standard for the Production of Software (Software Production Standard) (Ch 1, 5.2 Production of software 5.2.5, 5.2.6, and 5.2.12 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020’;
Ch 1, 4.4 Requirements for Producers of Software 4.4.8, ‘Agree Software Development Status (Ch 1, 5.2 Production of software 5.2.10 in the Provisional Rules and Regulations for Software to be used in Naval Ships, January 2020’.

Without early communication on these key points, it is possible that Producersof Software could make decisions and use approaches that do not meet the requirements of the NS Software Rules, and which could have programme impacts due to rework or additional assurance activities being required.

One area that should be given particular attention is the way the degree of reliance placed on the achievement of the Relevant Hazard Requirements is interpreted by the Producer of Software. Although determining and expressing Relevant Hazard Requirements are primarily system and Engineering System level activities, the Producer of Software and LR must be able to interpret the requirements. If the degree of reliance is expressed in terms that align with international standards, such as a Safety Integrity Level (as used by IEC 61508 and IEC 61511) or a Design Assurance Level (as used by RTCA DO-178C), it is relatively easy to understand which processes, methods, and techniques need to be used in the Production of Software. However, if more general terms such as ‘Critical’, ‘Safety Critical’, ‘Safety Related’, ‘Essential’, or similar is used, careful definition of the terms is required, and these terms, and the suitability of proposed processes, methods, and techniques, will need to be agreed with LR.

In respect of the Argument that is to be made for the Software meeting the functional objective, it is strongly advised that an outline of the Argument is used as a route map for planning the Production of Software which includes assurance activities. In this way, it provides more confidence that the Production of Software will naturally result in the evidence required to support the Argument. Producing an outline Argument that can support the planning processes is also likely to provide the necessary visibility to LR to enable suitable assessment activities to be planned.

The NS Software Rules assume a risk-based design has been used for the Engineering System and take account of the different assurance and assessment approaches applicable for Software of different Software Development Status. Therefore, while certain parts of the NS Software Rules are applicable to all Software, the degree of rigor and the scale of the activities necessary to meet the NS Software Rules will vary proportionately. It is also expected that the maturity, and LR’s experience, of a Producer of Software will lead to tailored assessments, minimising the disturbance to a Producer of Software. LR will also acknowledge and take appropriate recognition of the Producer of Software’s third-party assessment in its assessment planning.