37 articles
TechnicalA full battery, a cold morning and a long hill: the car does not slow down when the driver lifts off, and no part has failed. FMEA and FTA are usually driven by what can break. STPA starts from control actions and the context they are given in, so it prompts hazards where every component works as specified. New article, with one-pedal driving on a full, cold battery as the worked example.
TechnicalA CAN frame can pass every checksum on the bus and still carry the wrong request. One way to argue the integrity of a safety-related message rests it on the sender and the receiver, not on the network between them. This is the black channel idea, and the most common reason end-to-end protection exists. New article, with an electric parking brake release request replayed by a gateway as the example.
TechnicalA wheel alignment that touches no sensor and still leaves the stability control with the wrong idea of straight ahead. ISO 26262 Part 7 is where design intent survives the factory floor and the workshop, or gets lost there. The carrier is the safety-related special characteristic, and the service instruction decides whether a garage restores it or quietly undoes it. New article, with a steering angle sensor zero point as the worked example.
TechnicalA safety plan copied from the last program describes a project that no longer exists. ISO 26262 treats the safety plan as the safety manager's working tool: it starts from an impact analysis, records every tailored activity with a rationale, names a person for each activity, and is updated at the start of every phase. New article, with a carry-over shift-by-wire selector as the running example.
TechnicalNobody develops the whole item. Safety still has to hold across the vehicle maker, the supplier, the chip vendor and the software house. The Development Interface Agreement is how ISO 26262 makes that work: who does which safety activity, who is responsible, what is exchanged, and what happens when something goes wrong. New article, worked through on a battery management system: where an agreement is needed, where it is not, and the four questions it has to answer.
TechnicalA hazard analysis is only as good as what it was told about the system. In ISO 26262 that is the item definition: the boundary of the item, its operating modes and the vehicle situations they meet, actuator capability as numbers, the interfaces to other items and the assumptions behind them. New article, worked through on a power sliding door: where the boundary goes and what the hazard analysis needs to be told.
TechnicalAn agent writes four hundred lines in eleven minutes. Tests included, coverage at target, analyzer clean. ISO 26262 has no clause for AI coding tools, and ISO/PAS 8800 says it does not cover them either. The existing rules already do: generated code is code, and each use of the assistant is a tool use with its own confidence level. Drafting code can sit at TCL1. A model that replaces a human reviewer, with nothing behind it, cannot. New article on where AI assistants and agents help, where they bite, and a policy that fits on one page.
TechnicalHow ISO 26262 handles parameter data: why the software build separates configuration data from calibration data, how each value inherits its ASIL, what a parameter specification and its verification cover, and which mechanisms detect unintended changes of calibration data in the ECU.
TechnicalHow to evaluate a safety culture in an ISO 26262 organization from evidence rather than slogans: where safety collides with the schedule, which five project records show the real culture, what the functional safety audit and assessment already see, and three common misreadings.
TechnicalWhy ISO 26262 Part 2 regulates the organization: what safety culture means in the standard, how processes drift through the normalization of deviance, why responsibility needs authority and competence, and which of four checks asks which question.
TechnicalTwo redundant channels are not automatically independent. What a dependent failure is, the difference between common cause and cascading failures, the coupling factors that tie elements together, and why ISO 26262 asks for DFA.
TechnicalSoftware has no failure rate, so ISO 26262 cannot count it. What the standard asks for instead, why software is both the safety net for hardware faults and a source of its own, and why Part 6 converges on the software architecture.
Keep learning
Each guide is a full course with diagrams and worked examples. Open one to see what it covers.