IEC 61508-3

Select IEC 61508-3:2010, Edition 2

Software and its system context

The IEC public description covers software forming part of, or used to develop, safety-related systems within Parts 1 and 2. It identifies software lifecycle activities, development support tools and information passed to system integration. Operation, maintenance and modification information are also part of its described subject.

For procurement, specify the role of the software and who owns the system-level decisions. A software supplier cannot clarify an undefined system assignment merely by agreeing to a standard number. Give it the information needed to establish its work boundary and ask it to list unresolved assumptions.

What should travel with a software delivery?

The table proposes commercial questions rather than reproducing a lifecycle checklist from the standard. The responsible development and assessment team must define the technical work and evidence for the project.

Questions before signing the development contract

• Which functions and system interfaces are included in the software assignment?
• Who approves requirements and handles incomplete or conflicting information?
• Which tools or third-party components are used, and how are their versions recorded?
• What evidence will accompany each agreed release and the final handover?
• Who reviews a defect correction or requested change after the supplier's initial contract ends?

Clarify access rights and support arrangements early. The buyer may need source information, build instructions or supplier assistance for later changes. Define those deliverables explicitly rather than assuming that receiving an executable includes the ability and rights to maintain the whole project.

Example: outsourcing a safety-related firmware change

A product manufacturer commissions a firmware supplier to add a function to an existing safety-related controller. The initial quote names coding and testing, but it does not identify the existing evidence baseline. The buyer supplies the current version register and asks the supplier to describe the affected work and required information.

The revised contract names the delivered release, evidence records and information needed by system integration. It also identifies who will review unresolved assumptions and future defect fixes. The result is a clearer purchasing assignment; the example does not assess the firmware or approve the proposed change.

Connect releases to the system evidence

Use a shared configuration identity between software delivery and the hardware or system assignment. A report for one firmware version cannot be assumed to describe another merely because the product name remains unchanged. Ask for a comparison and an explanation of the review performed.

Separate completion of the supplier's work from acceptance of the integrated system. Agree what the integrator will receive and when it can raise questions. This makes the handover useful and avoids a contract milestone that closes the supplier assignment before important interface issues are answered.

Frequently asked buying questions

Is this a general cybersecurity document?

The verified title concerns functional safety software requirements. Define any security assignment separately with the responsible team rather than assuming this purchase covers every software risk.

Does Part 3 apply without the other parts?

The IEC public description places it within the Part 1 and Part 2 system context. Determine the document set from the team's responsibilities.

Does a test summary finish the handover?

Compare it with the contracted evidence package and release baseline. Ask how remaining assumptions, integration information and modification support will be delivered.

Related guidance

Continue with IEC 61508-1, IEC 61508-2 and the electrotechnical overview.

Explore more standards buying guides

Browse standards by reference and subject to compare related document choices.