ZVEI Leaflet Prescribes Software Tests for Fire Detection Systems

The established testing procedures for fire detection systems have long guaranteed the highest safety standards. Yet those procedures no longer meet the current speed and flexibility demands of software-based technology in a digitalized world. The current guidelines of the German Industry Association ZVEI now offer initial recommendations for automatic software testing, and describe them using fire control panels as an example. Axel Kunze, Head of Software Architecture, Fire Detection Systems, and Jorge Zingg, Head of System Testing, Fire Detection Systems, Siemens Building Technologies Division explain the details.

The CE mark verifies that the components of fire detection systems also meet the requirements of the European Construction Products Regulation (BauPVO). A notified body (NB) verifies conformance based on defined functional tests. Still, modern fire detection systems have more and more built-in software that requires regular mandatory updates. System manufacturers therefore face the challenge of keeping their products CE-conformant. Every update requires re-testing and release by the external notified body – usually in its own laboratory, or in exceptional, contractually agreed cases, at the manufacturer‘s location.
The disadvantages of this regulation are obvious: It is expensive, but most of all extremely time-consuming. As for IT security, the regulation no longer meets current user or manufacturer requirements. If, for example, a virus or cyber attack is imminent, speed is of the utmost importance. In other words, the system-saving software update cannot go through months of testing with the notified body.
Although less compelling, the same is true for updates that boost system efficiency and functionality.

Possible Ways Forward
Information technology points to one possible way around this dilemma. The test pyramid concept from agile software development has proven useful. Intensive test automation at all levels of the pyramid permit implementing new features in quick succession while ensuring that the existing functionality remains intact.
The difference from the Construction Products Regulation world, however, quickly becomes clear. Software is generally not required to pass through a defined release process with an external notified body, but a fire detection system is. In principle, there are two different approaches to achieving faster response times. You can split the system into separate parts, one relevant for approval and the other not, or you can integrate the approval step into the agile test process.
The first option quickly proves untenable, because today‘s software-intensive systems are not easy to disentangle. In embedded systems, many system parts are indirectly linked via shared resources, which prevents their full separation.
Furthermore, cyber-security gaps often lurk in deep software layers that can potentially affect the overall software.
We are therefore left with the second solution: merging the approval process with agile, automated test methods. The Safety & Security Division of the ZVEI (Central Association of the German Electrical and Electronic Industry), with representatives from all German manufacturers of fire safety technology, has now developed recommended solutions and summarized them in a ZVEI explanatory leaflet [footnote]. After all, it is not about gutting the tried-and-true approval system, but ushering it sensibly into the new age.

ZVEI Recommendation
The guidelines published at the end of 2017 apply to all products in safety and security technology systems, such as fire control panels, smoke and heat exhaust systems, etc., as listed in Construction Products Regulation (EU) 305/2011. Using fire control panels as an example, the document explains how to handle software modifications within the relationship of manufacturer and notified body in accordance with the BauPVO. In particular, it lays out a requirements profile on integrating the approval process into the agile development process, or in other words, how to design the process of agile software certification in the future.
First a look at the current process. If a newly developed fire control panel is ready for the market, the manufacturer requests initial testing by the notified body. If testing is successful, the notified body issues the required certificate for this exact version of the product. The new ZVEI recommendation revolves around an automated test system capable of performing the functional tests currently performed by the notified body and documenting them in a comprehensive test report. So in the future, on initial testing the notified body defines a test system together with the manufacturer. The test system and the test report are approved by the notified body. The actual testing then follows and the test system is “sealed“.
Sealing relates to the documentation of a specific, verifiable scope of performance and functionality by the recording of software and hardware version states (test system) and by means of suitable configuration management. Testing of the test system may be performed either simultaneously with testing of the product, or at different times.
The test system is subject to version control. Modifications are permitted only in consultation with the notified body. Changes to the system to be tested (test unit) that result in a “green“ test report can, as pre-arranged, be officially released on the market without resubmission to the notified body, with or without a new certificate according to the manufacturer‘s requests. Modifications to the test unit that require adjusting the test system require re-approval of the test system.
The advantage of this recommendation becomes evident when the control panel software is modified. Instead of full re-testing, the changes and the complete system are tested using the defined automated test system. Once the test has passed, the notified body receives documentation and/or a description of the software change and the test report from the test system.

Implementation
The exact nature of the system and the requirements it must meet remain open. It must deliver results that are precise and infinitely reproducible, and complete verification per the EN 54-2 standard must be ensured. It must be obvious which version of the test system is being used, and it must be approved by the notified body. Furthermore, it must always be clear which function was tested and how. The test system must also adapt to continuously changing product characteristics. It must also be possible to provide an overall assessment of the functionality. Finally, to be practical the test system should work without unduly tying up personnel and time.
No malfunctions may remain undetected during the actual testing. The various input stimuli must be as realistic as possible. Disruptions must be simulated in compliance with the standards. At the same time, system responses in terms of function and execution time must be verified.
In practice, an automated test system consists of intelligently combined real and simulated components. For example, as a major manufacturer of fire detection technology, Siemens has been using such test systems for years where most functions can already be tested automatically during the different development phases. In particular, the systems are able to simulate all possible situations and a “virtual tester“ reviews and confirms standards-compliant functionality. All Siemens test systems are submitted for validation to the external notified bodies.

Summary
In the current guidelines, the ZVEI offers specific and realistic recommendations on how to integrate the proven approval system per the Construction Products Regulation (BauPVO) and the agile, contemporary test process for software-based fire safety technology. The result: Users and manufacturers alike can rely on the same high safety standards but still respond very quickly to new requirements or security gaps.
VdS Loss Prevention of Cologne, Germany – known as the inspection body for fire control panels in Germany – also recently published its own guidelines (VdS 3837) that detail the requirements and testing methods for test systems, thereby further legitimizing and anchoring the described process.