Test and Validation of Electronic Control Units
Testing electronic control units within the overall system
A control unit can pass individual functional tests and still behave differently than intended during integration. Tests of the interaction between hardware, software, interfaces and connected components complement the evidence at component level. Together with other required analyses and tests, they show whether the product meets its specified requirements.
Silver Atena plans and carries out tests for electronic control units and systems. We test behaviour under defined operating conditions, at system limits and in specified fault cases. The results are compared with the requirements, and deviations are analysed and documented for further development. The documented results support the technical assessment ahead of a release decision.
Challenges in testing complex control units
With every additional function, the number of interactions in the system increases. An input signal influences a control function, which processes data from other components and triggers a response at an interface. If each part works on its own, this does not yet prove the behaviour of the entire chain.
States outside normal operation can also be important for testing. What happens at a specified system limit? How does the control unit react if a signal is missing or a defined fault occurs? Which response is required by a safety requirement? To address this, the relevant requirements are translated into suitable, reproducible tests.
It must also remain clear what has not yet been tested. A passed test says something about its defined test scope. For the assessment of the overall product, it is also crucial to know which requirements are covered by test cases, which results are available and which issues remain open.
Services in Test & Validation: software, hardware and system testing
Silver Atena tests development results at software, hardware, integration and system level. Verification assesses whether specified requirements are met. Validation assesses whether the system is suitable for its intended use. The tests required for this are defined by the project. For validation, we consider agreed application scenarios under representative operating conditions. We assess whether the system performs its intended tasks and meets the expectations of users and customers. Depending on the project, this takes place in a suitable simulated or real operating environment.
Our test teams examine individual functions as well as the integrated control unit. They derive test cases from requirements, select suitable test environments and compare observed behaviour with expected behaviour. Deviations are documented and analysed with the development teams involved. After a correction, we retest the affected functions.
The focus is on functional testing and assessment of the product. Environmental loads such as temperature and vibration, as well as formal qualification evidence, are covered by environmental testing and qualification.
Test strategy and test planning
The starting point is the question of which requirements need to be tested at which level. Some characteristics can be examined early on individual components. Others only become apparent once hardware and software are integrated or the control unit interacts with its environment. Silver Atena plans test levels, test environments and test scopes to suit the development status and the project-specific verification requirements.
Requirements-based test specification
Requirements are used to create test cases with defined preconditions, test steps and expected results. The product version tested and the test environment used are also recorded. Each test case is linked to the requirements it verifies. If a requirement changes, this makes it possible to determine which test cases need to be adapted and which tests need to be repeated.
Software, hardware and integration testing
Tests at the individual development levels check software and hardware against their requirements. During integration, the connections between components come to the fore: are signals transmitted and processed correctly? Do functions respond to one another as specified? This makes it possible to narrow down problems before the complete product is assessed.
System testing with hardware-in-the-loop
In the system test, the integrated control unit is tested against its system requirements. On the hardware-in-the-loop (HiL) test bench, the real control unit is connected via its interfaces to an environment simulated in real time. This allows defined situations to be repeated under controlled conditions. What conclusions the tests allow depends on the test set-up and on how well the simulation reproduces the characteristics of the real environment that are relevant to the test objective. Where necessary, tests with real components or in the actual operating environment complement this evidence. The tests check whether the response matches the requirement and how the device behaves at specified limits or in the event of defined faults.
Test automation and regression testing
During development, functions, interfaces and software versions change. Recurring tests can be automated and re-run after changes so that their results remain comparable. Which tests need to be repeated depends on the changed requirements, the affected components and an assessment of possible impacts.
Fault analysis, test reports and release recommendation
If the observed behaviour deviates from the expected result, we record the deviation and the boundary conditions. We check whether the deviation can be reproduced and narrow down the cause using test and measurement data. The results are passed on to the responsible development teams. Test reports document tests, results, deviations and open issues. Together with requirements coverage, they form the basis for assessing the verification status and preparing a release decision. The release itself follows the agreed project process.
Test process: from requirement to test report
The test process begins with an analysis of the requirements and the planned integration status. From this, we derive what is to be tested, at which test level the test is meaningful and which environment is required. The test cases are then specified and the tests prepared.
During execution, we compare the actual behaviour with the expected result. We document deviations and analyse them together with the responsible development teams. After a correction, the test team checks again whether the affected requirement is met. From the assessment of the change, we also derive the necessary regression tests to check possible effects on other functions and interfaces.
At the same time, the documentation grows: requirements are assigned to test cases, test cases receive results and deviations remain traceable until they are resolved. At the end, it is therefore clear which functions have been tested, which evidence is still missing and which open issues are relevant to the next decision.
Test coverage and traceability of test results
Many passed tests do not automatically mean that all requirements are covered. What matters is the link between a requirement and suitable evidence. For each requirement to be verified by testing, it should be clear which test cases were planned and carried out and which results are available. Other requirements may require suitable evidence through analysis, inspection or demonstration.
This assignment also helps when changes occur. If an interface is adapted or a function is revised, the affected test area can be identified precisely. Traceability therefore supports both technical work during development and the later assessment of the verification status achieved.
Test methods and project-relevant standards
Our methodological toolkit includes requirements-based verification, testing at different integration levels, HiL-based system testing, test automation, measurement data evaluation and traceability. The methods are selected according to the product, test objective and project requirements.
In the automotive sector, Automotive SPICE serves as a model for assessing development processes. For safety-related electrical and electronic vehicle systems, ISO 26262 can impose requirements on verification and validation. ISO/SAE 21434 addresses cybersecurity engineering and may require corresponding tests. For civil aircraft systems, SAE ARP4754B can concern system development and its evidence; RTCA DO-178C and DO-254 address development assurance for software and airborne electronic hardware respectively. The specific test and verification scope depends on the product, the project and, where applicable, the certification context.
Test and validation in automotive, aerospace and defence
Silver Atena aligns test planning with the product and its intended use.
Automotive
In automotive projects, control unit functions and their interaction are tested across defined test levels. In addition to functional requirements, safety requirements and the documented traceability of results can shape the scope of testing.
Aerospace
In aerospace, planned and documented verification is essential for the required evidence. It must be possible to link tests to the applicable product and project requirements.
Defence
For defence applications, functional tests are based on the specified operational scenarios.
Benefits of requirements-based testing for your development project
Systematic testing shows where a product already works as required and where further development is needed. A reproducible deviation can be investigated more precisely than a one-off observation without documented test conditions. This makes root cause analysis and the verification of a correction easier.
Linking requirements, test cases and results creates transparency about the development status. It helps to plan further tests and assess open issues before acceptance or release. Identified deviations can be assessed and addressed before the next project step.
Test and validation in interaction with development, test systems and environmental testing
Meaningful test cases require clear requirements. That is why testing works closely with requirements engineering, system architecture, hardware development, embedded software and function development. Where relevant requirements exist, we involve the functional safety and cyber security teams. The test teams report anomalies back to development and retest the results after a correction.
Many tests require suitable test environments. Test systems and test bench development provides test benches depending on the project. Our test teams plan the product-related tests, carry them out and evaluate the results. Environmental testing and qualification complements the functional evidence with tests under the specified environmental loads.
Why Silver Atena for test and validation?
Silver Atena combines the development of electronic control units with testing of the integrated product. The direct exchange between testing, development and test bench development helps to consider deviations in their technical context: does the cause lie in an individual function, at an interface or in the interaction of the system?
Our experience with projects in automotive, aerospace and defence feeds into the planning of the tests required in each case. The results are linked to requirements and documented in a way that makes them usable for further development and the technical release assessment.
Discuss test and validation for your project
Are you developing a control unit and want to test functions, interfaces or the integrated system? Talk to Silver Atena about which requirements need to be verified and which tests are required.