Remote control monitoring solutions with IEC 60730

Household appliances today have become ever smarter, and the demand for latest innovative features is seemingly endless. Especially, the connectivity that brings remote monitoring or control from across the room or across the world is now common thing. IEC 60730 “Automatic electrical controls” is also a derivative of IEC 61508. It focuses on electrical and electronic controls associated with or used within household appliances – for example, heating and air-conditioning systems. Despite the increasing complexity of their products, household appliance developers are required to ensure that the likelihood of injury to people or damage to the property resulting from their use is very low, even in the event of negligence. The primary purpose of IEC 60730 is to define a process that will ensure these targets are met by ensuring the functional safety of these products. 

The standard provides technical guidelines applicable to any automatic electrical controls. These can take many forms. For example, they may:

Form part of an appliance,

Be individual controls utilised as a part of a control system, or

Be mechanically integral with multifunctional controls having non-electrical outputs.

Classification of appliance software:

IEC 60730 discusses mechanical, electrical, electronics, environmental endurance, EMC, and abnormal operation for home appliances. For the evaluation of protective measures for fault tolerance and avoidance of hazards, it classifies control functions according to their potential impact in the event of a fault:

Class A – Control functions that are not intended to be relied upon for the equipment’s safety and have no feature that can harm a human being. For e.g. humidity controls, lighting controls, timers.

Class B – Control functions that are intended to prevent unsafe operation of the controlled equipment. E.g.: thermal cut-offs and door locks for laundry machines.

Class C – Control functions that are intended to prevent special hazards. E.g.: automatic burner controls and thermal cut-outs for closed, unvented water heater systems. For a control to be compliant, it needs to comply with all aspects of the standard in terms of software involvement. The extent to which that requirement places an overhead on a software development team, depends on the classification of control functions when, as Annex H confirms, “their integration into the complete safety concept of the appliance shall be considered.”

Application of IEC 60730 process activities:

Constructional requirements for control systems are specified in Clause 11 of IEC 60730-1 2013 which includes the “Controls for Software” detailed in Annex H.11.12

 

The lifecycle activities:

Specification of Requirements: During the control system design phase, functional requirements and safety requirements are refined, and software and hardware elements are identified.

The primary objective of specification for the resulting software safety requirements is to describe every safety-related functions and non-safety-related function to be implemented, including functions related to the detection, annunciation, and management of software and hardware faults. These descriptions should include details of response times, related software classes, and interfaces between hardware and software. The requirements verification activities the review will consider whether the requirements have been defined in accordance with best practice characteristics and attributes for good requirements are followed. Establishing traceability for backward and forward requirements coverage ensures that all requirements are met.

Software architecture: The primary objective of this clause is to ensure that the specified software architecture fulfils the standard’s requirements for the relevant control class. The architecture is required to be analysable and verifiable, and capable of being modified without compromising safety. Static and Dynamic aspects are defined in the standard to be implemented and be verified as being in accordance with the specification of the software safety requirements to ensure the correctness and completeness.

Design and coding: Software is required to be designed in accordance with modular principles, and to reflect the architectural design, such that the design and the resulting code is traceable to the software architecture, and hence to requirements. The design is required to specify function(s), interfaces to other modules, and data. Coding standards like MISRA C/CPP, CERT C/CPP, and CWE will help to define programming practice including naming conventions, proscribe unsafe language features, and specify procedures for source code documentation. LDRA Tool suite applies the Static analysis techniques to verify that the resulting application code represents and accurate interpretation of the module specification. By applying these best practices, the resulting code will be as secure, reliable, error-free, and easy to test and maintain as possible. For example:

Large, rambling functions with complex interfaces are difficult to read, maintain, and test – and hence more susceptible to error.

High cohesion improves maintainability and reduces complexity

Verification: Best practise dictates that static and dynamic analysis of the code should be an ongoing process while ever it is under development. The code implementation process is therefore interwoven with ongoing static analysis, and with module and integration testing. Module level testing is first to ensure that modules have been implemented in accordance with the low-level design specification and hence fulfil all specified safety functions and control functions. Unintended functionality must be also be shown to be absent. As software modules are integrated together, testing of the resulting software subassemblies and ultimately the complete integrated system is validated with suitable test cases based on the software safety requirements specification. Tracing the low-level requirements to source code and test cases can be challenging, because of the different tools typically used for requirement management and source code development. The TB manager component of the LDRA tool suite can help performing it.

Structural coverage metrics: In addition to showing that the software functions correctly, dynamic analysis is also used to generate structural coverage metrics. In tandem with the coverage of requirements at the software unit level, these metrics provide the necessary data to evaluate the completeness of test cases and to demonstrate that there is no unintended functionality. Statement, branch and MC/DC coverage are provided by both the unit test and system test facilities of the LDRA tool suite.

Conclusion:

When supported by a complementary and comprehensive suite of tools for analysis and testing, the adoption of that process can smooth the way for development teams to work together to effectively developand maintain large projects with confidence in their quality, simplifying the development processfor Class B and Class C software in accordance with IEC 60730.

————————————————————————————————–

Authored by

Deepu Chandran, Senior Technical Manager, LDRA

————————————————————————————————–