Software Change and Evidence
Software, configuration, and intervention evidence matter when they are necessary for safe operation or critical for compliance with the relevant essential health and safety requirements. The Regulation also treats some later digital changes as substantial modifications when the legal definition is met.
Safety software must be identifiable
identify the software installed on it that is necessary for it to operate safely
Regulation (EU) 2023/1230, Annex III section 1.1.9
The requirement is narrower than a complete software inventory. It concerns software installed on the machinery or related product that is necessary for safe operation. The information must be available at all times in an easily accessible form.
In practice, the safety-relevant set may include safety-related application software, firmware, robot controller software, safety PLC logic, drive safety parameters, HMI software used for safety instructions, and configuration files that set safety limits.
Intervention and configuration evidence
Annex III section 1.1.9 requires evidence of legitimate or illegitimate intervention in relevant hardware, software, software modification, or configuration. prEN 50742 uses the draft term intervention for an action or event that changes software or data and modifies or interrupts machinery behaviour, state, or operation.
Updates and modifications
Software updates, firmware changes, safety-related application software changes, and configuration updates can be interventions when they affect safety-relevant software or data.
Evidence and tracing logs
Evidence can be digital or physical. prEN 50742 treats tracing logs as records of interventions that affect the safety-related control system.
Readable identification
The useful record identifies the software version and configuration in a form a person can read, by built-in display or a commonly available external tool.
Protected records
Evidence must remain trustworthy enough to support the safety conclusion. A log that can be silently changed does not prove the intervention history.
Control system records
Annex III section 1.2.1 adds a specific tracing-log rule for control systems. The tracing log of intervention data and uploaded safety software versions must be enabled for five years after the upload, exclusively to demonstrate Annex III conformity in response to a reasoned request from a competent national authority.
For machinery with fully or partially self-evolving behaviour or logic, Annex III section 1.2.1 also addresses recording data on the safety-related decision-making process for software-based safety systems ensuring a safety function, including safety components.
Substantial modification
A later software or configuration change is not automatically a substantial modification. Article 3 defines substantial modification as a physical or digital modification after the machinery or related product has been placed on the market or put into service, not foreseen or planned by the manufacturer, that affects safety by creating a new hazard or increasing an existing risk and requires the listed protective changes.
Foreseen software updates should be addressed in the original risk assessment and technical documentation when they are foreseeable at placing on the market or putting into service.
A later digital change can fall into the substantial modification definition when it is not foreseen or planned by the manufacturer and it changes the safety conclusion in the way Article 3 describes.
The Regulation's recital states that repair and maintenance operations that do not affect compliance with the relevant essential health and safety requirements should not be treated as substantial modifications.
Information for use
Instructions for use must cover intended use and reasonably foreseeable misuse. For software and cybersecurity, the useful information is the information that affects safe use: version and configuration identification, permitted and prohibited modifications, access to intervention evidence, security context assumptions, and any compensating measures expected from the user.
- state the safety-relevant software and configuration identifier;
- explain how the user or authority can access the identifier or evidence;
- identify modifications that are permitted, prohibited, or outside the manufacturer's intended use;
- state security-context assumptions that affect safe use, such as trusted network boundaries;
- avoid presenting a user countermeasure as a substitute for required safe design.