Safe operation of software-controlled lifts
Is this lift safe to use until its next periodic inspection? Lift experts and maintenance personnel are expected to answer this question clearly and unambiguously – potentially challenging in practice, as safety functions in modern lifts are software-monitored and digitally controlled. The solution is based on effective and continuous verification of the firmware’s product safety and its safety in use.
To ensure lift safety even in the presence of faults, demands on lift safety components such as safety gears have always been subject to high demands. In Germany the same as in the rest of Europe, lifts may only use safety components that have passed type examination (assessing design, construction, material, workmanship, load limits, etc.) and proved that they always fulfil their safety functions reliably.
Type examined for safety functions
As technological change leaps forward, many safety functions that used to be mechanical are now embedded systems, monitored and controlled by hardware and software (HW/SW) systems. Modern lifts contain safety circuits, with a typical architecture including sensors, logic units and actuators (hardware), that digitally generate, process, evaluate data (software) and trigger actuators.
Lift shaft information systems, for example, identify safety-relevant faults in the dynamic behaviour of the lift and reliably place the lift in a safe operational state. In regular operation they monitor the lift’s position whilst travelling as well as its levelling accuracy, and allow the precise measurement of other dynamic parameters such as acceleration and speed.
The qualified data provided by these systems can be used to identify safety-relevant faults and initiate effective countermeasures. In this context the HW/SW system must reliably identify all hazardous operational states and process them correctly, the detection of overspeed travelling being one example. On the other hand, however, the system shall also minimise “false positives”, such as triggering the safety gear unnecessary in regular safe operation.
Directive 2014/33/EC of the European Parliament and of the Council of 26 February 2014 on the approximation of the laws of the Member States relating to lifts and safety components for lifts
Stickers raise questions
Inspectors often find control units bearing only a sticker with the version number of the installed software version (SW) but no indication of when the sticker was affixed or whether the information is still up-to-date and correct. Has the SW been updated meanwhile, or perhaps even a new version installed? If so, is the update qualified and suitable for the HW-setup, who performed the update or installation and why, and does it impact on the safety functions? When the lift is connected to the Internet, is manipulation by unauthorised parties excluded? Can the company rule out unauthorised or unintentional manipulation by, say, a service technician?
In periodic inspections, these questions are often hard to answer. The inspectors must search for evidence, review documentation and access authorisations and, in particular, check test results and information from the original type examination, which informs about the system configuration and the SW installed in the examined type that was approved for use in a safety function … and of course qualified SW-updates. If the experts cannot determine without doubt that the control unit SW is still the same as in type examination, they cannot confirm that its use will be safe.
Working together: Hard- and software
SW testing and qualification are thus clearly essential parts of type examination as they ensure the functional safety of the lift system in case of a fault.
While SW updates may be executed and new versions developed and installed, the important principles of the safety life cycle of SW development must be complied with in the same way as it is done with HW. Yet, this is not always sufficiently guaranteed.
The methods and qualities for ensuring the reliability and effectiveness of safety-related functions required in SW development differ from those required for hardware components. That is because SW is subject to systematic and intended errors only – failure rates and reliability data cannot be calculated as it is common practice in HW qualifications.
All professional methods are characterised by typical quality assurance activities as clear goals, instructions, responsibilities, and authorities. Feedback, meetings, test environments and simulations keep developers informed of important findings about shortcomings, incompatibilities, programming errors or malfunctions, while milestones in important project phases ensure source-code verification and SW validation. In this context, experts rely on traceability, the four-eye principle (two-man rule) and other proven and tested quality assurance measures to prevent systematic faults.
Unlike HW, SW is not subject to wear and tear, i.e. there are no random faults. Causes of systematic faults include inadequate implementation of the requirements in SW specifications, unsystematic use of anchor links and variables or insufficient test coverage. These faults must be excluded through efficient quality assurance.
DIN EN ISO 9001 “Quality Management Systems – Requirements”
Functional safety requirements
Safety-related electrical, electronic and programmable electronic systems (E/E/PE systems) are considered to achieve the intended risk reduction if they fulfil the requirements of the IEC 61508 series of standards [1]. Part 3 of this series specifies the requirements regarding safety-related software. This part defines safety life cycle, tools to be used and the documentation quality. It is thus particularly relevant for software and applies to all PESSRAL (=Programmable Electronic Systems in Safety-Related Applications for Lifts) in the scope of Directive 2014/33/EU [2] in the EU.
In addition to special software-related requirements, IEC 61508 also addresses general requirements for safety functions realised as HW/SW systems which ensure reliable achievement of the necessary Safety Integrity Level (SIL) which indicates the expected risk reduction to be achieved through the specific PESSRAL.
A functional safety management system according to IEC 61508 is critical in this context. Like the ISO 9001 standard [3], it establishes quality assurance along the supply chain, demanding that HW and SW suppliers, but also inspection organisations establish functional safety and apply it correctly.
Furnishing proof of safe lift use
The existing system configuration must thus be documented in an equally thorough and traceable manner as every safety-related change to the lift system (e.g. sensor replacement, firmware update). Compliance with this requirement is generally ensured in the form of a suitable configuration management system.
In periodic inspection, a sticker or note with a QR code is often found in the lift documentation. By scanning the code and entering the correct password, the expert can access the entire documentation of the lift. The digital file includes all relevant information at a glance. In case of remote software updates, the expert verifies the integrity of data transmission.
Further evidence and certificates by accredited bodies then prove that cybersecurity measures correspond to the state of the art and that the lift control unit is protected against software manipulation and malware. Information on these aspects can be found in the IEC 62443 series of standards [4].
This type of documentation answers all questions on IT security and functional safety, enabling experts to confirm that use of the lift will be safe until the next periodic inspection. This “futuristic” form of verification has already become reality as all stakeholders have realised that it supports easy and continuous verification of lift safety, which benefits everybody – and lift users in particular.
TEXT and PHOTOS: Dr. Rolf Zöllner, TÜV SÜD Industrie Service GmbH
Monitor and Reduce Motor Operating Temperature to Increase Reliability
