The process of reviewing, writing, managing, and implementing requirements within functional safety is important in the automotive industry. Requirement implementation is especially important for testing-correction-retesting, which ensures validation. When engineers run these tests, they can determine whether these applications are operating within their intended functionality.
In this blog series, we will be focusing on the functional safety requirements process, as well as the key factors of success when handling these projects with a variety of customers in the industry. This is the first article in a 2-part series:
One of the key measures of success within functional safety is if these implementations work as engineers expect them to or not once testing begins. That way, these processes can lead to safer automotive mechanics and towards safer roads.
It is easy to look at both functional and technical safety requirements, either confusing them or merging them as one altogether. What is the difference between the two exactly? In short, aside from their requirements, both technical safety and functional safety are concepts used to measure the safety of products, including equipment or software. Functional safety looks at the broader glimpse of how systems need to operate, while technical safety looks at more specific details.
The test requirements within functional safety offer benefits to organizations from both an internal and external standpoint. You can achieve organizational success with several of these advantages, such as:
Overall, the purpose of both is to make sure that organizations’ products not only function in a safe and efficient manner but, more specifically, within their intended functionality.
In order to implement requirements into a system, engineers must first review and write them. During the reviewing process, it is key to understand the setup of what organizations have and how they use it, because each level of the hardware setup will be different. After engineers understand that they can start writing the requirements.
The reviewing process often involves examining if the requirements need to be linked or not. Indirect and direct requirements must be linked but derived required don’t because they just require rationale. Indirect and direct requirements are those that come from an organization’s requirements documents, based on system needs. Derived requirements, on the other hand, are based on application software. In other words, these are additional considerations to investigate in the reviewing process, emphasizing the importance of engineers collaborating with other teams.
When requirements are not properly reviewed beforehand, it can lead to problems during the writing phase. Organizations may find themselves asking other teams of engineers to investigate what their system is doing because, in some cases, their own teams cannot present the issues it might have. For example, there will be instances where calibration data may be used without anyone confirming it was correct. Engineers can provide a deeper understanding of the relevant aspects of functional safety, giving organizational guidance on how to apply it to different systems. Setting up reviewing efficiently sets up the writing for success.
There is an overall importance in managing and supporting functional safety requirements because the process essentially reflects the level of operational efficiency products and software have.
Requirements management is a step before implementation, while the support aspect comes after. For some projects, organizations will distribute hundreds of documents to the engineering team they hired for the implementation of their requirements for a proper review. After that, the team would be asked to then import the requirements onto a tool used for management. When handling large amounts of requirements for implementation, there must be an organized way put in place to manage them. The tool used depends on the organization involved and the overall needs surrounding the project itself.
Once the requirements are implemented, the team supports what is developed by verifying and validating that the software is applicable when testing begins. Verification and Validation—a process often referred to as V&V—allows engineers to guarantee that organizational demands are achieved and satisfied so that products and/or software will function as intended. Engineers often view this step as software quality control, which can be viewed as an extra safety net to guarantee proper testing.
Verification comes before validation, but you can look at each exclusively in parallel until everything is adjusted and functioning properly. In verification, engineers ensure that they are building software the right way. They may ask questions like, “Are the requirements precise?” or, “Do the requirements we implemented have gaps?” Validation attempts to identify any errors in the software implementation that is unstable. If there is, the software will cause issues during testing, so engineers ensure that they are building the right software. Validation helps ensure that the software application is doing what the initial requirements demanded. In some cases, the software can be built incompletely or incorrectly, creating a disconnect in what is desired.
Many engineering teams further review these requirements, coming to an agreement that they are applicable for testing. Since there are several attributes to each requirement, they collaborate with multiple teams. Once everything is reviewed and approved, testing can begin.
The short answer is, it depends. Since projects tend to vary with different organizations and their overall needs, how a team of engineers works with test requirements varies as well. The organization’s experience with requirement implementation is a factor that often influences what the process itself will look like. Some may have their own teams focused on different sectors of the process, such as:
There may be projects where engineering teams are asked to take on specific roles, which can be a slight change in what their tasks may be. Some organizations will have specific teams—a systems team, for example—dedicated to writing requirements and importing them onto a management system they use. While they have a team focused in that area, they could have their engineering team on-call to examine any defective requirements that need to be repaired. That team could focus on attribute reviewing, and even work with the functional safety team to analyze the requirements. Or different engineers on the same team could be split up to work in a few different areas, to remain efficient. Depending on the organization, it is obvious that engineering teams can have significant amounts of flexibility while working on requirement projects.
Organizations will find that optimizing their requirements in every step of their product development is key for guaranteeing efficiency and success. From a procedural standpoint, actively focusing on requirements establishes a base foundation for products’ overall goals, cost, timeline, and quality. From an engineering standpoint, requirements add context for what capabilities a product should have and how it is supposed to operate. Within automotive, an industry where vehicular technology and innovation is growing rapidly, being able to verify and validate product requirements is essential. The process of reviewing, writing, managing, implementing, and continuously supporting products’ functional safety requirements is what allows for test criteria to be defined. Whether doing this for new products or modifying existing ones, the end result is often having good test requirements.
To ensure that the industry as a whole achieves safer roads and quality technology, prioritizing functional safety requirements is important for organizations to do. In part two of this blog, we’ll examine what collaboration with customers can look like when approaching test requirement projects, and how that affects functional safety requirements altogether.
How to Approach Test Requirement Projects with Different Customers