IEC 61508-2

Buy the published second edition

Part 2 within the IEC 61508 family

The IEC public description links Part 2 to systems containing electrical, electronic or programmable electronic elements. It addresses refinement of system requirements into design requirements and system design and manufacture. Software is treated in Part 3. Its scope also identifies information for installation, validation, operation, maintenance and modification.

For a buying decision, begin with what the supplier is actually delivering: a component, subsystem, product development service or integrated system. Those assignments need different information from the buyer and different evidence at handover. Record the boundary before comparing suppliers.

A supplier-to-system evidence map

A claim on a product brochure may be a useful starting point, but ask for its exact scope and supporting information. The system team needs a usable explanation of what the product evidence establishes and what remains its responsibility.

Questions before awarding the hardware order

• Which functional safety work is included in the supply contract?
• Does the evidence identify the exact offered product and version?
• What assumptions or restrictions must the integrator evaluate?
• Who provides the information required by the operating organisation?
• How will proposed substitutions or design changes be reviewed and recorded?

Ask for a responsibility schedule with named deliverables. A supplier may provide a component evidence package but exclude application engineering. Another may offer a wider service. Make those differences visible before comparing the unit price or development fee.

Example: selecting a monitored output module

A system designer compares two output modules for a proposed safety-related system. Both suppliers advertise functional safety capability. The buyer requests the exact assessed version, conditions of use and integration information for each module, then asks the responsible designer to compare those assumptions with the project.

One offer requires additional application work that was absent from the initial price comparison. The final purchasing decision includes that work and records who will perform it. The example does not assign an integrity level or judge a module; it shows why product evidence and system responsibility must be connected.

Agree the assessment basis and handover baseline

Keep the required functions and system assumptions in an agreed project record. Ask the supplier to identify which information it needs to perform its assignment and which issues must be resolved before design acceptance. This gives purchasing staff a concrete basis for milestones and change requests.

At handover, connect drawings, version identifiers and supplier evidence to the delivered baseline. Agree how later maintenance questions reach the responsible technical team. Information that is available only during development can become difficult to recover when a replacement product is needed years later.

Frequently asked buying questions

Does Part 2 replace the general framework?

Use the parts as a coordinated document set. Define the team responsibilities and review the Part 1 buying guide for the broader assignment.

Does a product claim establish the whole system result?

Ask what the claim covers and how its assumptions are evaluated in the proposed system. A component designation alone does not describe the entire integration evidence.

Where does the software purchase fit?

Part 3 addresses the software subject. Link the hardware and software evidence through a shared configuration baseline and agreed responsibilities.

Related guidance

Read IEC 61508-3 software purchasing and the electrotechnical overview.

Explore more standards buying guides

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