The role of writing functional safety requirements in the realm of automotive functional safety is to provide a clear understanding of the needs for implementation, independent of the Automotive Safety Integrity Level (ASIL). It is important to clearly define what is going to be implemented, and how it is going to be implemented. This is accomplished through the creation and use of two key documents that are scoped and tailored to the automotive industry:
Combined, these two documents provide a very powerful tool to answer these questions about your system:
Requirements are very important to answer these questions. They are a key aspect of understanding the goal of your system, and they distill these greater considerations into specific actionable items. This could be applicable not only to your engineering system but also for marketing your interactions with a customer during all aspects of customer product development. They help you understand what you need to do and then how to implement it. You then add more details, and more information, to make it possible to implement your design.
Writing requirements also help to document all of the design decisions. It is critical that the appropriate documentation is in place to demonstrate why a design was chosen, and to record the tests that were performed to confirm that the design is good, correct, and implemented as intended.
Writing requirements is a crucial aspect of systems engineering overall, especially now that we are going into the new development of autonomous vehicles where there are many new functions and new functionalities. This entails a large quantity of automation, which in turn is adding a lot of complexity to the systems. The more you document your decisions, the easier it will be to manage changes.
Once you establish an initial version of your document or your requirements, you may need to make changes. Let's say you have a vehicle, and you have added a considerable amount of new features compared to the earlier version. It is impractical and unnecessary to start from scratch. Instead, you will be updating the existing design. How do you change a single requirement and not affect all the other aspects and interactions of the vehicle and the system?
A hierarchical and organized set of requirements can help. You can find what is affected by the change that you're proposing. Then, regression testing and integration testing can be performed to make sure you did not break anything that you didn’t intend to, and that only the elements that you wanted to change were actually impacted.
Requirement writing is a very important tool for analyzing and understanding the impact of change. Once you establish a change control process, the requirements guide you as you implement modifications in the vehicle or system, by providing traceability in the documentation.
There are practices to follow for writing requirements that are pretty much universally accepted. Even across different types of industries, we tend to follow the same principles and guidelines on how to write requirements. However, the content in the requirements themselves varies, depending on the industry. For example, requirements for automotive will be different than for pharmaceutical, even though they are written using similar overarching practices. It is at the content level that requirements tend to become more specific to an industry or company.
One of the first aspects to consider is clarity. Writing good requirements is almost like an art form because it is so difficult to get clear concise requirements that are not ambiguous. Something that is obvious to one person, might be vague to another. And if it is clear to just one co-worker, we might be tempted to stop there and check it off as being completed. However, that is not sufficient. A requirement must be clear to everyone.
For example, someone who has worked with me for five years might read a requirement that I have written and understand it with no issue, because they know me well and they know my communication tendencies, how I think, and how that translates into my writing. However, if someone new jumps into the project, they won’t have that same context and that requirement might not be clear to them. A requirement needs to be very clear to everyone who is going to use it. So, understanding the principles and standards of writing good requirements, and applying them in a way that makes the requirements understandable for everyone who reads them is very important.
Even though the need for achieving clarity is universal, and the principles and guidelines that define good requirements tend to be consistent across industries, the step-by-step process of writing requirements may vary from one company to the next. One example is when we are working with a small company. Let's say our typical team of engineers is working on the project: three software developers, three software validation testers, three safety engineers, and three systems engineers. A team of twelve from safety systems, software, and validation. It is a small team; they could all work in the same room, and thus communication risks would be reduced simply by proximity and availability. Have a question? Just turn around and ask. In a case like this, if it is a less complex environment in a smaller company, you can tailor and simplify the process to fit the needs of your project and team.
However, these team scenarios can vary greatly. In comparison, right now I am working on a project where we regularly meet with 35 engineers, just to talk about requirements writing validation. If you have a huge number of requirements, and 30 engineers working on the same module and the same requirements at the same time, you must be very specific about what to look for and how to review it. You must establish very clear, detailed instructions, that are adhered to by everyone involved.
Some companies come to us with questions about the degree of work that they must do. They have a product that is functioning and working properly. It does what it should. They ask if they can get by just documenting it as-is. The short answer is no. If you don't have a clear and vetted understanding of what it should be doing and don't have those requirements documented, then how can you know if it is doing what it should? You must first define the requirements before you can perform all the analysis and testing. If you have not defined proper and complete requirements, you cannot say your equipment is or is not safe, because you don’t have anything to measure it against.
Poor organization of requirements is a particularly troublesome issue that can have many negative impacts. The information must be easy to find, easy to use, and easy to understand, in that order:
I've seen quite a few examples of customers that don't organize their requirements very well. They start writing the requirements and you try to follow them, but you can't find what you are looking for. Or you find it, and it is not complete. Either deficiency is very dangerous.
When information is inaccurate or incomplete, people tend to deviate from proper processes and apply shortcuts and on-the-fly workarounds. Instead of looking at the requirements to get the information they need, they call someone whom they think might know the answer and say, “Hey, do you remember that failure that we were discussing the temperature sensor? What's the behavior? Because I can't find it in the requirements, they are very hard to understand.”
At that point, the requirements become useless. The person they asked might know the answer, or they might not. The person asking the question might eventually receive an email response about the reaction time for that temperature sensor, or they might not. Or even worse, the information they receive may be inaccurate with no ready way to confirm, because the root source can’t be traced. Or, the data might be buried somewhere in the requirements, but it is so hard to find that nobody uses it. And even if they do somehow identify the right person and get the right info and it happens to be accurate, the process is not readily repeatable. The knowledge is fleeting, tribal. It could be lost as soon as one of the key people leaves the team. Then, the company will once again have to pay in time and resources to rediscover knowledge they have already paid to acquire at least once. Disorganization and wasteful rework have a direct negative impact on profitability.
There are some requirements that are not specific to safety. However, when writing safety requirements, the priority is to organize the reactions to unsafe conditions, rather than trying to define every conceivable cause. If you get that backward, it becomes an impossible task where you are essentially trying to define every possible root cause based on the assumption that you already know every possible root cause. The problem is that you don’t know what you don’t know. No one does.
To better illustrate what happens when the prioritization of reaction and cause is flipped backward, the following is an example of organizing, and one of the mistakes that I have seen:
Typically, there is the detection of a failure, and then a response to the failure. The requirement answers the question, “What needs to happen if that failure is detected?” However, it is easy to get the logic backward and slip into trying to project every possible theoretical cause of that unsafe situation, rather than focusing on the reactions when that unsafe situation occurs.
In this instance, we wanted to understand which failure modes would place the vehicle in a degraded state that would still allow for the safe operation of the vehicle in a limp-home mode. (For example, a failing engine sensor may trigger a degraded mode. If my equipment is normally able to provide 100 horsepower and 6000 rpm, in degraded mode, it will only provide 30 horsepower and 2500 rpm. It can still be driven in a degraded yet safe condition that allows the driver to safely move it over to the side of the road, but the lower speed reduces the operating temperatures, thus reducing the risk of greater damage to the engine.) However, what happens if you have 10 different elements in 10 different components in your system? Suddenly, the puzzle becomes much more complex and moves beyond a single instance of cause and effect.
Each system is made of different components, and each component contains different sensors and actuators. Each one of those different components is evaluated, and if it fails, the system response to the failure of that component is defined. Then the actuator is evaluated, and it is determined how the system will respond when the actuator is engaged. All of this information helps define possible system modes for this event. In turn, that information is cascaded outward to 10-30 different failure modes across those 10 components. Attempting to predict all the theoretical causes for possible failures quickly becomes a vast and complex web of information. The engineer may spend hours trying to determine all the different possible causes. It is a daunting task. They may never be sure if they found all the right information. But if they focus more on organizing the reactions instead of predicting all of the possible causes, the task becomes much more manageable.
The ideal situation would be to describe how the failures would be detected on each sensor, each actuator, and each element of the system. Then, define how the system will react to these faults, grading them by the level of reaction. And then, group them together by level.
Another common problem is that companies often don't provide clear guidance or training on how to properly write requirements. They lack examples of what to do and what not to do, so their people don’t know how to utilize the proper processes in an optimal manner. And the lack of a clearly defined review process can consume extra time through unnecessary steps. Lacking proper guidance, their haste can make the entire process take much longer.
When deadlines get tight, requirements often change frequently. Meanwhile, you are trying to review them. You review a requirement and the next day, discover that it has changed because it wasn’t written properly in the first place. Your review from yesterday is no longer applicable, and you must review the requirement again. All that time and effort is wasted.
Being trained to write requirements properly the first time, and being trained to follow the proper processes every time, reduces wasteful rework and cuts down on time-consuming full-blown reviews for minor incremental changes. And when things are changing quickly, configuration control becomes even more important. No shortcuts! It is imperative that the order of changes be documented accurately in a manner that is transparent and traceable, or else the result can be chaos.
Requirements that are properly written and maintained, play a critical role in defining and implementing functional safety. Learning how (and why) to write requirements, and then learning how to work within a proper system, correctly, the first time, is all a part of proper training. It is a real challenge when you must be proactive while you are being reactive, but these are not tasks that you can just bluff your way through. Writing requirements is both an art and a science that can be taught and learned.