Software/Systems Engineering Projects: Preparing for Regulatory ApprovalFollow article
How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Almost all products now need regulatory approval, be it CE Marking, or specific product approval testing to ensure that the product is safe for use. If you are designing and manufacturing physical products the product approval process is well understood. However, in the areas of software and systems engineering, the regulatory approval process may not be quite so well understood, or the impact of the process appreciated.
This blog, and the following two "The Impact of having regulatory requirements on a Software project" and "How to work with the independent Regulator", are aimed at those engineers who are interested to understand more about the approval process that may be required before a software system can be brought into service.
I am a practising software/systems engineer who has spent most of my working life in the heavily regulated industries of defence and aviation where systems need to be approved prior to their introduction into service. My interest, and therefore the focus of these blogs, is in giving insight into what I have experienced to date about bringing software systems that have varying levels of safety criticality in terms of keeping people safe during their work or leisure activities into service.
These blogs are by necessity written at a high level as well as being a personal look and review therefore I have deliberately left examples generic and anonymous to protect everyone! I hope that they prove an insight into an area that might be either new or of interest to you.
For a contract, the customer will identify relevant standards that are applicable, and that the customer expects you, as the supplier to follow. For internal projects, the project team might need to look for the relevant standards if the project is in a domain that is new to the company. Some examples known to the author regarding standards include:
- Airborne Software: RTCA DO-178C (then select filter: software). There is also a Wikipedia article here.
- Ground Air Traffic Management Software: EUROCAE ED-109A
- UK MoD: Def Std 00-56 There is some background information here.
- Medical Software: The MHRA provide some overall guidance here. They have provided guidance on how medical devices are regulated which can be found here. There is also EU Directive 2017/745.
As well as safety standards, there are other standards that will need to be considered by the project team. Some example security standards include:
- Information Security Management: ISO27001
- ISO Standards for Information Security Management in health: ISO27799
- ISO Standard for medical devices: ISO 13485
All of these standards have been through a rigorous development process and have wide acceptance within the relevant communities so it’s well worth reading them and understanding them. Note, however, that some of them will need to be purchased, for example, RTCA DO-178C costs $290 (price correct as of 19/2/2021).
If the customer contract and/or requirements are silent on relevant standards, then I would encourage the project team to open a dialogue with the customer to determine the right standard to use. Ideally, this should happen pre-contract award as the implication of the relevant standard and in the case of safety, the safety criticality level of the software will have a significant impact on both the time taken and the cost.
At the start of the project, whether it is a contract awarded or an internal project, it is important to identify what might be needed by an independent regulator, because trying to reverse engineer the design or documentation can be significantly expensive or even almost impossible without returning to the design activity and starting almost from scratch, thereby incurring significant time delays and cost.
Once the standards that need to be adhered to are agreed upon, then there needs to be a detailed study of the standard to determine what constructs are permitted and what documentation is needed. On one of the projects, the contract stated that the development should adhere RTCA DO-178B so the project team reviewed that to determine what impact that would have on the development and how it impacted the design, time and cost. The earlier this is done and the earlier that you start to engage with the regulator, the better as there might be ways of tailoring both the design and the process followed to minimise additional work.