Ready for certification? Applying safety requirements to your UAS
UAS Certification is a quality assurance process applied by a third party -the certification authority-, demonstrating your aircraft system is compliant with the certification specifications. Most of these specifications and requirements are focused on safety. Especially talking about systems and equipment. In this post I will be tacking the different points to bear in mind to take into account how to undertake the certification process in the most efficient way.
This is the first post of a series or posts focused on tackling safety requirements in your development project, from the planning perspective, the design organization, and the product.
The certification plan and understanding safety requirements.
The certification process of a manned aircraft is most of the times a commonly known process for aviation authorities because the specifications are normally clear given that the application of a manned aircraft is already well known. However, what happens when we get into the fancy world of the unmanned aircrafts? Well, things change drastically, each concept of operation is different from the rest, the specs of the platform are extremely specific, and we can find plenty of innovative aircraft configurations from VTOL to electric and hybrid.
In my opinion, the best way to reduce the amount of complex and redundant systems you will have to install in your aircraft is to have a good approved certification plan. In your certification plan, you state and rationale the specifications your system will have to comply with. Therefore, if you are capable of simplifying the level of complexity and the demands in your certification plan, your development project will be less costly and your product more competitive.
Regarding systems reliability, there is always a section in the certification specifications regarding systems reliability. In manned aviation is commonly under section 1309. You can check JARUS document as reference (JARUS AMC 1309). In this section, each functional failure of your UAV is related with certain “criticality” and event probability. For example, catastrophic events are requested to happen with extremely low probability, given their impact. The higher the criticality of the event to happen the lower the probability required.
That assigns for each of the systems involved in the failure of that function a failure probability, a development assurance level and sometimes the need for avoiding single failure. In summary, you will have a set of reliability requirements for most of your UAS’s systems and equipment.
In Certified UAS the certification specification assigns the development assurance level and additional architectural requirements apart from failure probability. The development assurance level or DAL commits to the application of certain processes and procedures to the development process, and the generation of documentation demonstrating that such level has been reached and that system level requirements are accomplished by the item.
The safety assessment
Once you have your system safety requirements, you will have to foresee how your system and your system architecture will be to comply with those. To do such thing, in the aerospace context is normally recommended in the AMC/GM of the Certification Specifications the ARP4761 as the main reference to follow, because it gathers the complete process and is widely used in the aerospace industry. Although, it requires high level of understanding and experience of the different studies and methods included in the process to generate valuable results.
Designing a system architecture in aerospace is much more than covering pure functional requirements. It is about complying with functions, availability, and safety. Each one of the items of your architecture performs at least part of a function. In case this item fails, and depending on how it fails, the function would be lost. That is where the criticality of the function would tell you to accomplish additional integrity improvements at system level.
Some of the tools used are the Functional Hazard Analysis and the Fault Tree Analysis. Both tools let you identify which functions have higher criticality in your system, so their realization at items and component level must comply with your safety requirements. Then you build a potential architecture for your system and assign those functions to items and units. In that stage you can check whether your system architecture complies with the safety requirements or not. This is an iterative process that requires deep understanding of the process and the potential system architectures, until to reach the desired safety level.
After sharing the implications of the system architecture in the safety requirements, you may have noticed how important is to treat this part of your development project very carefully. These activities and decisions have a huge impact in your system costs and development time.
Requirements management and safety compliance
Requirements management process is an iterative process that goes from high level requirements identification to item level. It is used the V-model approach to perform this process together with the verification and validation. Therefore, no requirement is left uncovered.
I have seen many companies making special focus on the safety requirements, implementing the measures required and justifying their compliance just for the safety needs, not paying special attention to the functional or performance requirements for instance. That may allow them to demonstrate that their system complies with the Certification Specifications, but most of the times it becomes an unsafe and useless product, and I will tell you why.
When covering just part of the requirements of the system in the process, many other features become not relevant, and that may lead to skipping not identifying other important requirements. In the end, additional capabilities the product must have to be usable. For example, one company with special focus on the certification of their 70kg UAS missed to specify the required endurance of their aircraft. They ended up having 20min endurance because they could not carry more than half a liter of gasoline.
In other cases, the functional requirements are missed and therefore their integrity is not reviewed. For example, some maneuvers where required in the operation, but they were skipped due to their focus on safety. Later on in the project, they decided that the pilot would perform whatever the aircraft cannot perform automatically. In the end, those maneuvers where more critical than expect and in certain failure cases, such as communication link loss those could not be performed. So, finally, they did not comply with the safety requirements because they did not pay attention to cover all the aircraft capabilities required.
Following the V-model is much more than a heavy system engineering process, it is a quality assurance process. ARP4754A states the process to perform the design assurance process behind the safety requirements and demonstration, but it is nothing without a quality system.
I have been working for organizations with very heavy and paper-based systems engineering processes and plans. Their projects involve hundreds of engineers, officers, pilots and technicians. They were certified under ISO9001 and ISO9100, but in the end their quality system was not properly implemented, or their resources working in quality were not enough.
They had the rules and they knew the processes, but they were not following them. There were always some changes added in an uncontrolled way, or non-conformities not reported. Therefore, the problem was not just that the project costs were running out of control and the project schedule was continuously delayed. The main problem is that it was impossible for them to comply with their Certification Specifications and safety requirements, so they struggled until they passed.
Complying with safety specs is not a big deal. The big deal is not to have the right organization to oversee them.
Just the right tools with the right processes
We are no longer working with typewriters and paper-based procedures. If you want to reach that safety level and quality assurance in your organization, you may have to think of alternatives to reduce the costs. A traditional paper-based approach would waste a lot of resources in bureaucratic and repetitive activities and having the right tools would help you save a lot of time and money.
There are software tools with higher or lower level of complexity and capabilities. They may help you manage product requirements, system configuration, or even help you model the system before producing it. However, do not think that they will define your development process and procedures for you. A tool is a tool. It may implement your process or part of it, but it should have been defined before configuring the tool for your needs.
For example, some organizations decide to buy expensive requirements management tools without taking a process to implement the configuration management in their project. The results are catastrophic: uncontrolled and redundant requirements, not validated, or properly derived.
So, if you want to implement processes that will provide the quality assurance level required in design phases first define your processes and then choose the tools that would suit you best. Nevertheless, trying to implement those heavy processes the old way or with the wrong tools will definitely reduce your development pace.
Most UAS manufacturers aiming industrial and civil applications, that now would be under specific category, have been following a consumer grade UAS or hobbyist approach. That approach is excellent if you want to develop a demonstrator in the short term. However, certified UAS need a long-term strategy with clear objectives, even if you want to apply agile or lean philosophies. Now, new regulations have changed the rules and they find themselves far from what is required for an airworthy UAS. Unfortunately, the gap between one and the other is so big that most of the times requires almost an entirely different culture and mindset.
Another relevant point is that innovative projects are full of decisions not considered before and unforeseen risks. Whether the issue is to choose one technology or another, or to properly implement certain system requirements, the main problem lays on the fact that a certified UAS development project is something not many people has been through before. It does not matter if your company is used to the aerospace industry or this is your first certified UAS.
Therefore, whether you find many uncertainties along the development process or you feel that your organization needs updates, involving professionals with experience in certified UAS is always the best option. Especially those with a wide view into the development project. Setting the right path for the development of your product will assure success in your UAS certification and you will save time and money.
In Abionica Solutions, we have been more than a decade working on small and large Unmanned Systems. We provide project management and systems engineering oversight to support our customer’s organization towards their product design and certification.