AS ISO 19014.4:2022 – Earth-moving machinery —Functional safety Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system.
3.22
independence of software
exclusion of unintended interactions between software components, as well as freedom from impact on the correct operation of a software component resulting from errors of another software component
3.23
operational history
operating data about a software component or a software module (319) during its time in service
3.24
maximum cycle time
static time to access a communication bus between nodes at a bus or node level
Note Ito entry: The application of a time-triggered protocol ensures this cycle time is not exceeded.
3.25
maximum response time
fixed time assigned to a system activity to exchange globally-synchronised messages (3.6) on a bus in a time-triggered architecture
3.26
software fault
incorrect step, process, or data definition in software which causes the system to produce unexpected results
3.27
Impact analysis
documentation that records the understanding and implications of a proposed change
3.28
configuration management process
task of tracking and controlling changes to the artifacts (3.9) In the development process
3.29
constant transmission of messages
situation in which the faulty node continually transmits messages (3.6) that compromises the operation of the bus
3.30
blocking access to the data bus
situation In which the faulty node does not adhere to the expected patterns of use and makes excessive demands of service. thereby reducing its availability to other nodes
4 Software development
4.1 General
The main objective ul the tukluwmg icquilements is Lu achieve sultware rdiablity by means ut readable, understandable, testable, and maintainable software. This clause gives recommendations for the design of software and the subsequent related testing. The avoidance of software faults shall be considered during the entire software development process.
Where an existing software component has been developed to a previous standard and demonstrated through application usage and validation to reduce the risk to as low as reasonably practicable, there shall be no requirement to update the software life cycle documentation at the software module level.
Machine control software shall comply with the safety requirements of this clause. In addition, the machine control software shall be designed and developed according to the principles of ISO 12100:2010 for relevant but not significant hazards which are not dealt with by this document.
In this case,
— one measure From Measure 1, Measure2 or Measure 3 shall be fulfilled for MPLr = a, b, C;
— one measure from Measure2 or Measure 3 shall be fulfilled for MPLr = d, c;
— otherwise, a rationale shall be provided about the unspecified alternative method/measure to satisfy the requirement of the standard for the specific MPLr,
Rationale or justification shall he provided if other equivalent methods or measures are used instead of the listed methods or measures.
If a software component has any impact on different safety functions with a different MPLr, then the requirements related to the highest MPLr shall apply.
If the software contains safety-related and non-safety-related components, then the overall embedded software machine performance level achieved (MPLa) shall be limited to the software component with the lowest MPLa; this requirement does not apply when adequate independence between the software components can be demonstrated in accordance with Clause 7.
When reusing a software component that is intended to be modified, an impact analysis shall be performed. An action plan shall be developed and Implemented for the overall software life cycle, based on the result of the impact analysis, to ensure that the safety goals are met.
4.3 Artifacts
Once the individual phases of software development plan have been determined, the artifacts shall be defined for each phase to be carried out, Other phases and related artifacts can be added by distributing the activities and tasks. Taking into account the extent and complexity of the project, all artifacts in the individual phases shown in Figure 1 may he modified.
NOTE It is common to combine individual phases if the method/measure used makes it difficult to clearly distinguish between the phases. For example, the design of the software architecture and the software implementation can he generated successively with the sante computer-aided development tool, as is done in the model-based development process.
As part of the software development process, the artifacts shall be:
a) documented according to the outcomes expected from the planned phases;
b) modified as a consequence of an intpact analysis, and only the impacted software shall be regression tested;
c) subject to a configuration management process.