ISO26262 Standard - Page 1
Forum section: electronics / projects

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 08:11:17 am
content: Hi,Is there anyone who has worked with ISO26262? I am designing a system for automotive industry and they require it should be according to ISO26262 Standard. If anyone can give me kickstart on it or any documentation it would be really nice.Thanks

author: capt bullshot
author_rank: Super Contributor
timestamp: July 20, 2017, 08:54:53 am
content: First, you should check if the 26262 applies to your system, and which level of safety integrity is required.26262 is a standard for functional safety, similar to the industrial 61508. Same big picture but different in detail.If this standard really applies to your service, consider yourself screwed and seek professional assitance (in case you don't have experience in functional safety).Designing a system according to any current functional safety standard starts with defining your / establishing a given development process, defining safety goals and required safety integrity levels, then doing various FMEAs at different levels, starting at system level, and ending with validation of your requirements.Did you note that I haven't mentioned basic hardware/software design? Yes, thats part of the required development process in the middle stages, but the required process covers way more than this (the whole product life), and a simple "safety circuit" that is taken from somewhere isn't worth anything without the whole lot of paperwork ...And yes, I've been part of a team designing an industrial safety drive control system according 61508 etc. from scratch with no experience in functional safety, successfully at least, the whole process took about 5 years (maybe more, I don't remember).First thing to do if 26262 applies to your product: seek some professional training courses to get into it (in Germany - go to TUV Rheinland for industrial stuff, don't know about automotive)

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 09:08:22 am
content: Yes it is our prime focus to have ISO26262. We have chosen MCU and System basis which are certified with ISO26262. It has built in selft test for Internal clock. I/O etc. I will add additional DAC and ADC for the selftest and fault diagnosis.DAC will inject current on different signal paths and ADC will measure it. With this technique we can have check on all I/Os. What do you think?So we will have following features for functional safety:1. BIST within MCU2. BIST for overall architecture using ADC& DAC3. Power supply and high current ouput drivers fail safe switchI am responsible for the hardware and software guys will work around hardware.

author: capt bullshot
author_rank: Super Contributor
timestamp: July 20, 2017, 09:15:24 am
content: Yes, these are the usual techniques for HW design here, looks OK on first sight.Using a certified MCU (I'd expect it to be certified as SooC - Safety element out of Context) is a good starting point for the HW part of the design. Be sure to follow the Safety and Integration manuals - most of the tasks apply to SW anyway.Do you have someone doing the paperwork required for certifying your system? This person should have set up various development / integration and testing / valdiation plans.Just using certified components doesn't give you any safety for your system.

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 09:19:44 am
content: we hired a firm to do the paper work for us and they will deliver in 3 to 4 months and in the meanwhile we cannot stop our HW design.If you have any documentation regarding HW Design according to ISO26262 that would be nice. So far my idea about this standard is more you want to know more data will come up to confuse you.Please do let me know if you any kind of documentation regarding that.

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 09:21:45 am
content: Our MCU is MPC5744P which is suitable for ISO26262 ASIL-D chassis and safety applications

author: Jeroen3
author_rank: Super Contributor
timestamp: July 20, 2017, 09:21:53 am
content: Quote from: capt bullshot on July 20, 2017, 09:15:24 amYou don't even need to use those certified parts. That is just marketing.Audits do not look into technical details, they look at independent test results and documentation.Customers however... they might ask for an audit of firmware or hardware.What do you mean, hired a firm to do paperwork?

author: AndyC_772
author_rank: Super Contributor
timestamp: July 20, 2017, 09:28:11 am
content: I'm curious. What is it, specifically, about an MCU which means it "is suitable" for safety critical use?Is is the case that an MCU without some particular certification is automatically "not suitable"? Why?

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 09:29:36 am
content: It was management decision to hire some firm to give us detail insight about ISO26262 and how to implement it. They decided to make a prototype first and then will change it according to ISO Standard but i already finished the schematics design for prototype 2 months early from the deadline so i want to implement that standard into this prototype too.

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 09:36:40 am
content: @AndyC_772For Example:1. Dual processing spheres including; CPU, DMA, interrupt controller, crossbar and MPU for logic level fault detection2. Two statically configurable modes of operation: Lockstep operation (redundant processing and calculations) and dual parallel mode (independant core operation)Fault collection unit, which monitors and manages fault events.3.Error correction coding on RAM and flash memory allows detection/correction of memory errors4. PINS Short-circuit detection5. Dual-core lock step6. ROM Integrity check and ECC7. RAM BIST and ECC8. Analog IO BIST, error-injection check9. SPI-protocol checker10. Undervoltage (UV) and overvoltage (OV) detection on outputs

author: AndyC_772
author_rank: Super Contributor
timestamp: July 20, 2017, 09:50:11 am
content: Quote from: sanwal209 on July 20, 2017, 09:36:40 amOk, thanks. They sound like entirely reasonable features for an MCU to have, which would help a designer produce a system which can detect certain faults, and presumably, take appropriate action.It's not clear to me, though, that simply choosing such an MCU would automatically achieve compliance with any particular standard; only that it might make the practicalities of meeting such a standard easier.I'll be interested in how you get on with having an external company deal with paperwork. I'd have expected the compliance documentation to be intimately linked to the way the hardware is designed, tested and validated, and certainly not a thing that can be done in isolation.

author: capt bullshot
author_rank: Super Contributor
timestamp: July 20, 2017, 10:25:04 am
content: I don't have any documentation nor links to such about HW design according to 26262. I've got some training material (and a lot of experience) according to 61508 etc., but my boss or someone else will hurt me substantially if I give that out ...Most of the relevant HW design requirements should be covered by the MCUs manuals, especially the safety manual.Yes, in theory, the HW design process should integrate the additional requirements and paperwork for functional safety. Same is true for SW dev. In practice, this isn't the case in many projects for many real world issues like "the boss wants a quick and cheap result and doesn't care about quality documentation / formal design process or whatever".Then there's still the additional stuff like safety plan, V&V plans, lifetime cycle managment, safety goal and safety integrity level that isn't covered by a non-safety realated development process.Neither an "safety certified MCU" is automatically suitable for your safety project or even gives you automatically a safe product and nor a non-certified MCU isn't suitable for a safety device.Using a certified MCU often is just the simpler way, as the vendor has pre-done quite an amount of safety-specific things for you (self-checks, documentation, tables for FIT calculation, ...)Otherwise, using a non-certified MCU often is the cheaper way, by choosing the right top level architecture you can get around many of the MCU's internal self-check feature (more usual in the indutrial world, automotive tends to prefer single-chip solutions where you need all the self-checks).

author: capt bullshot
author_rank: Super Contributor
timestamp: July 20, 2017, 10:50:06 am
content: Quote from: sanwal209 on July 20, 2017, 09:29:36 amBrave man, you are. If you've done all the things required by the safety manual of the MCU (which can be very little, depending on whatever), there's nothing more that you can do now. Other safety related HW measures result from system and component level FMEA etc and cannot be easily predicted. You'll have to wait for their results. Usually, their requirements on HW design will then be verified and validated by their test plan - so if you do something now, most probably it will be the wrong thing that you'll have to reverse then.

author: sanwal209
author_rank: Regular Contributor
timestamp: July 20, 2017, 12:06:23 pm
content: Thanks for the help. I think i will stick to old plan with simple prototype because designing BIST for the hardware it is not gonna be an easy job.I totally understand your restrictions regarding docs sharing.Your feedback helped alot.CHEERS

author: AndyC_772
author_rank: Super Contributor
timestamp: July 20, 2017, 12:38:44 pm
content: Would you say there's a bit of a chicken-and-egg problem when it comes to the design and its FMEA?I'm struggling to see how the "paperwork" can be effectively outsourced, if the FMEA depends on the design, and the design depends on the conclusions of the FMEA. Surely either:a) the same people do both, orb) the process becomes highly iterative, and takes a disproportionate amount of time, effort and cost?

author: capt bullshot
author_rank: Super Contributor
timestamp: July 20, 2017, 01:31:41 pm
content: Well, that depends ...At the projects I did, usually there's first a bunch of top level block diagrams that get refined into modules block diagrams.Those are input to the system-level FMEA, resulting in a bunch of diagnostic measures, these go to HW component level design or SW (or both). Integratio level and failure injection test definitions start to exist here, to be refined later.Now, we've got a set of schematics (one for each module), these undergo reviews etc, maybe resulting smaller changes. Component level FMEA won't give surprises here (in case you've got enough experience to do things right from start on), component FMEA results mostly go into FIT calculation input. Module level test definitions start to exist hereNow the usual CAD / Layout / prototype mfg procedereOnce we have the prototype boards, testing starts, test results may lead to design changes, SW starts to get integrated with the HW, SW testing startsAt some point we have a near final product, validation testing against system level requirements starts, may lead to design changes (most in SW now)Thats what the 61508 standard calls the "V-Model" development process - if you want to do functional safety (industrial, don't know too much about automotive), you're stuck with this model. And yes, your first functional safety development procject takes at least three times longer than your standard project ...

author: AndyC_772
author_rank: Super Contributor
timestamp: July 20, 2017, 02:27:31 pm
content: Thanks very much. It's handy to have at least a rough idea of how much additional work is involved in producing safety-critical product X, as opposed to 'normal' (but nevertheless well designed, perfectly usable, and probably very reliable) product Y.

author: Scrts
author_rank: Frequent Contributor
timestamp: July 20, 2017, 06:45:30 pm
content: Quote from: capt bullshot on July 20, 2017, 08:54:53 amFully agreed. If you are designing ASIL rated system, then you need Preliminary Hazard Analysis, then out of that - Technical Safety Concept. The project has to have massive documentation. All DFMEAs, FMEDAs, FTAs done...But... Let's go from the first and most important thing: which ASIL level you're required to deliver?In automotive it's like this: if you're designing ASIL level part - every second think of what you're doing and how you will explain in great detail in front of a court.

author: floobydust
author_rank: Super Contributor
timestamp: July 20, 2017, 07:07:49 pm
content: Management grossly underestimates the amount of engineering work required for functional safety product development.You don't outsource the FMEA. Nobody wants to be responsible (=liable) for damages. A third-party can "assist" but will never sign-off on the FMEA.Who is your responsible member? Usually an PE engineer and their manager is not, which causes trouble.I encountered a faked FMEA- product causing explosions due to mosfet shorting, leading to product recalls- I couldn't believe the swarm of lawyers and dollars.