ISO 25119: The norm describes the safety requirements for tractors and machinery for agriculture and forestry. The standard is a sector specific implementation of IEC 61508 and consists of 4 parts. Like other functional safety standards, ISO 25119 specifies various levels of criticality. The standard defines the Agricultural Performance Level (AgPL) QM, a – e. The AgPL a to e correspond to the Performance Levels (PL) a to e as defined in ISO13849.

Regarding the software, an SRL (Software Requirement Level) is derived from the AgPL. Chapter 7.3.5 in Part 2 of the standard defines the relationship between AgPL and the SRLs (B, 1, 2, 3).

Structure of the ISO 25119

ISO 25119 consists of four parts. The first part primarily defines the management aspects of a functional safety project. The second part discusses the necessary safety concept and the requirements for risk and hazard analysis. The third part deals with hardware and software development and testing. The fourth part discusses the functional safety aspects in production, operation and in case of changes.

Development on system level according to ISO 25119

ISO25119 uses the V-model as the basis for development. This hardly differs from other functional safety standards. Like ISO26262 in the automotive industry, ISO25119 requires a Functional Safety Concept and a Technical Safety Concept. The V-model representation (Figure 1 of ISO25119-3), ISO25119 shows the relationship between the system requirements, the system architecture and the two concepts. However, ISO25119 also requires some experience in order not to add unnecessary complexity to the documentation structure at this point.

The functional safety concept should contain the functional system requirements and the technical safety concept contains the system architecture or the system design as an essential part. This point is very important in practice if you want to create a traceability that is easy to understand.

ISO 25119 Software Development

The planning of the software development process is at the forefront of software development, as well as in all functional safety standards. The planning is documented in the Software Project Plan.

Then the ISO 25119 Software Development defines a level of software requirements. In most cases these will be textual requirements which can be best managed in a database. The standard also requires a review of the requirements.

The next two steps in the life cycle are the software architecture, as well as the software component design and implementation. Regarding the requirements for software architecture and design, ISO25119 remains comparatively general. Many requirements are made on the implementation of the software.

Testing is divided into three areas in ISO 25119:

• Software component testing
• Software integration testing
• Software safety testing

For the software component tests, the proof of structural source code coverage is required for SRL 2 and SRL 3 projects. Since the proof of 100% structural coverage is not explicitly required, practice must show how much effort the projects actually put into this. However, if you have a proactive approach to project management and if you want to achieve good quality, you should look for tools on the market that can help you measure structural coverage.

Software integration tests are mainly used to prove performance requirements and integration aspects.

The software safety tests are the system tests. The focus here will be on tests in the vehicle.

Software-based parameterisation requirements

Like other, more recent functional safety standards, ISO 25119 also defines specific requirements for software parameterization. From practical experience, however, it should be noted here that ISO 25119 does not sufficiently discuss the test problem resulting from software parameterization. The test problem is that a parameterizable software is practically no longer 100% testable, since the possible test vectors tend to go towards infinity.

Conclusion

ISO 25119 is written in a more compact form than ISO 26262, and the requirements for safety in system and software development are also (significantly) reduced. This is mainly due to the fact that agricultural machinery, very often used on private terrain, and the speed of vehicles is also lower than that of cars. Therefore, the hazard potential resulting from the machines addressed in ISO 25119 is lower than the hazard potential of the vehicles addressed in ISO 26262.

Related HEICON Blog posts

• Functional safety and pragmatism – Is that possible?
• Good safety development process – What is it?
• Functional Safety – What is it?
• Quality Assurance in functional safety projects – Where is the difference?

The HEICON team will be pleased to support you with our services if you have individual questions regarding your project. Please send a mail to: info[at]heicon-ulm.de.