Author Topic: How do I handle programming for safety standards.  (Read 6831 times)

0 Members and 2 Guests are viewing this topic.

Online peter-h

  • Super Contributor
  • ***
  • Posts: 6058
  • Country: gb
  • Doing electronics since the 1960s...
Re: How do I handle programming for safety standards.
« Reply #50 on: January 22, 2026, 10:04:53 pm »
Quote
Asking for generic advice, like on this thread, will lead to nothing,

Not at all, because these are all useful pointers to additional research. One doesn't need an IQ of 150 to spot who knows what they are talking about.

It's like googling, or "AI". You get lots of pointers and eventually, having got clued up, you end up on the right path.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: Siwastaja

Online mtwieg

  • Super Contributor
  • ***
  • Posts: 1819
  • Country: us
Re: How do I handle programming for safety standards.
« Reply #51 on: January 25, 2026, 01:54:52 pm »
Full disclosure, I am not a software firmware engineer (though I do end up writing a great deal of bare metal firmware), I'm definitely not an expert on functional safety, and I didn't even stay at a Holiday Inn Express. But for a time my company was flirting with rolling our own embedded controller which would have required functional safety, including the software aspect, and I can suggest the following.

1. You need to identify the specific standard(s) you will be following. Sometimes the marks you are pursuing (CE, CB, UL, etc) will point you in the right direction. In our case this was for a medical device, so we were going to follow IEC 62304. If you don't know how to determine the right standard(s), I would contact the Notified Body you intend to use for certification (i.e. Intertek, TUV, etc), they will point you in the right direction (and likely charge you by the minute for the phone call).

2. I am only somewhat familiar with IEC 62304, and basically it is not at all a guide on how to write or design code. It is more of a set of guidelines on how to document the lifecycle of software, with different requirements based on the software safely class (basically how much harm could result from a software fault). But even this was quite vague, and didn't provide any sort of "recipe" to follow. For example, it never says that "in case X you need multiple cores in lock-step" or "in case Y you must use FLASH controllers which can detect/correct double-bit errors". A great deal is left up to interpretation.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18901
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: How do I handle programming for safety standards.
« Reply #52 on: January 25, 2026, 02:11:02 pm »
Well I guess that as I am doing everything bare metal and writing it myself I am probably no worse off than any other scenario should someone turn around and say: "how about we do some of the safety stuff ourselves". It's not my problem to worry about and I am probably on the right track already.
 

Offline Wim_L

  • Regular Contributor
  • *
  • Posts: 225
  • Country: be
Re: How do I handle programming for safety standards.
« Reply #53 on: January 25, 2026, 05:18:36 pm »
To clear up some confusion:

CE marking is put on certain types of products by the manufacturer. It declares that the product met EU requirements at the time it was put on the market. CE marking is only used on those products where some EU regulation or directives requires it. It is forbidden to use the CE mark on products that are not covered by regulation that requires it. Most electrical equipment will need it in the EU (due to low voltage, EMC or machinery directives, for example), but some will not (for example, electronics exclusively intended for installation on aircraft - different rules). EU regulations and directives have a 'scope' section to declare what is covered and what isn't.

In some cases, the manufacturer must involve external assistance for the conformity checking, the so-called notified bodies. Even then, the main responsibility for safety remains with the manufacturer. The legal definition of manufacturer is not necessarily the company which physically manufactures the device.

EU regulations/directives will specify requirements. Specifically, essential safety requirements (ESR). Sometimes those are pretty vague. For many products, there are harmonised standards. If your product is within the scope of such a standard, and you follow the standard, then you can 'presume conformity' for those ESR items that are listed in the annex ZA of the harmonised standard. In theory, use of such standards is optional. In practice, you need to prove 'equivalent safety' if you decide not to use one, which means you need to take the standard into account anyway. And the notified body might strongly dislike your approach because just following the standard test setups and filling the regular checkboxes is much more convenient for them than certifying a unique method none of their other customers uses. The EU maintains a list of which standards are harmonised for various kinds of devices: https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards_en

If there are no harmonised standards... Good luck! It may be an option to use other standards, best current practices (if documented), extensive in-house risk analysis,...

Standards do get expensive. Prices per standard are normally quite manageable, but standards organisations have this tendency to take a document that should logically be one standard, and then split it up into 5 to 20 separate standards, none of which makes sense separately until you buy all parts and read them together. Still, the cost of the standards you need will probably be much lower than the other costs of the project. You might be buying some unnecessary ones too, because you'll only figure out they don't apply to your situation after you have them.

Many of those regulations do not directly or explicitly regulate software (some do). For example, if you have a certain safety requirement for a machine, it must be satisfied. The rules usually do not care if you satisfy the requirement using a hardware solution or a software solution, only that it is satisfied. That must obviously be evaluated for each individual case.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->