Ploughing up the software gems in ISO 25119

As a consultancy, we often look for alternative sources of functional safety and technical information in different industries. This helps bring different views and perspectives to our activities. At the start of this year, we were working with ‘ISO 25119 Tractors and machinery for agriculture and forestry – Safety-related parts of control systems.’ This standard has a very clear and concise approach to dealing particularly with software topics. In this blog, we look at how ISO 25119 can support activities in standards such as ISO 26262 and IEC 62304 that we use on a daily basis.

ISO 26262 similar structure

ISO 25119 uses a table structure similar to that of ISO 26262 for defining the suitability of methods for specific activities.

Where:

SRL = software requirements level (3 being the highest);

+ = the method or measure shall be used for this SRL, unless there is a reason not to, in which case that reason shall be documented during the planning phase;

0 = there is no recommendation for or against the use of this method or measure for this SRL;

x = the method or measure is not suitable to meet this SRL;

A letter after a number represents an alternative method.

This structure is very similar to ISO 26262 but gives generally more direction on the suitability of the method. With each section of ISO 25119 describing a specific subject area, there are summarized the aims of each clause and then a more detailed description of the activities.

Software design and development tips

The methods and techniques listed for software design and development are similar to the topics covered in IEC 62304 and ISO 26262. However, the big plus point in ISO 25119 is the rationale and additional information on why such choices should be made. We will take a look at a few examples.

Owner & Consultant

Alastair Walker, Owner / Consultant

If you wish to take part in ISO 26262, IEC 62304 or other training courses or you are looking for consultancy in this area, please do not hesitate to contact us at info@lorit-consultancy.com.

Suitable programming language

Many teams stick with the language and tools that are at their disposal, but decisions on the suitability of newer programming languages often come into to play. IEC 62304 has a clause on risk assessing the choice of language, but ISO 25119 takes the activity further defining:

Fully and unambiguously defined;
Block structure;
Translation time type checking.

And should support:

Small and manageable software components;
Restriction of access to data in specific software components;
Definition of variable sub-ranges.

There are many other points listed too, which are helpful in guiding the choice.

Defensive programming

Also a well known subject, but in many sources often just defined as ‘use defensive programming’. ISO 25119 gives a good description of typical control or data anomalies.

Discussing the two overlapping areas of defensive techniques, the first set includes:

Range checking the variables;
Checking values for plausibility;
Type, dimension and range checking parameters of procedures at procedure entry.

The second set covering:

Checking input variables and intermediate variables with physical significance for plausibility;
Checking the effect of output variables, preferably by direct observation of associated system state changes;
Checking by the software of its configuration, including both the existence and accessibility of expected hardware, and also that the software itself is complete – particularly important for maintaining integrity after maintenance procedures.

On the software design side there are many other topics that are also well covered ‘information hiding/encapsulation’, ‘trusted/verified software components’ and ‘use of coding standards’. There is also a good annex on ‘independence by software partitioning’.

The proof of the pudding

As with all development, the aim is through good requirements management to get as much right by design as possible, but we are human beings and this may not always be the reality.

The guidance ISO 25119 gives on verification is also adding more detail than the 2 other standards mentioned earlier. There are good sections covering:

Boundary value analysis;
Control flow analysis;
Data flow analysis;
Structure-based testing;
Equivalence classes and input partition testing;
Avalanche/stress testing.

Summary

There are always different ways of looking at problems and implementing solutions. ISO 25119, particularly in the area of software, has a very pragmatic and helpful approach to describing what is required and also how to approach the topic. Standards such as ISO 26262 and IEC 62304 tend to provide less information on the ‘how’.

When talking about state of the art, then using sources from other industries can be helpful in understanding problems and defining solutions. As a safety standard for software engineers, ISO 25119 is certainly a good read.

By Alastair Walker, Owner / Consultant

If you are looking for functional safety support either through consultancy or training courses, please feel free to contact us via contact form or at info@lorit-consultancy.com.

CONTACT

Form

We look forward to hearing from you.

Contact

Address Austria:
Lorit Consultancy GmbH
Siezenheimer Straße 35
5020 Salzburg / Austria

Tel: +43 676 338 8884
info@lorit-consultancy.com

Address UK:
Lorit Consultancy Ltd
1 Craigathie Road
Roslin Midlothian / Scotland EH25 9BG

Tel: +44 7708 360023
info@lorit-consultancy.com

Partner of

Copyright © 2024
To top