Software and Safety
summary
Software runs in toasters, pacemakers and cars and different levels of harm demand IEC 61508 style evidence that code does not exhibit unintended behavior — ISO 26262 requires proof of absence of undefined behavior. Practical mitigations include sanitizers and hardened libraries, static analyzers like CodeQL and Clang‑Tidy, contracts/RAII/spans instead of raw pointers, fuzz testing and defense‑in‑depth. A production example: Woven by Toyota prepares open source C++ foundation libraries (Apache + LLVM exception) with no-heap inline containers for AUTOSAR/MISRA use.
AI-written summary · about
chapters (18)
- 0:00Software safety concerns
- 1:03Safety-critical vs related software
- 4:13Software failure consequences
- 12:24Industry safety standards
- 14:29Software failure root causes
- 19:29Undefined behavior in C++
- 23:01Handling unexpected inputs
- 30:50Testing strategies for robustness
- 35:43Detecting undefined behavior
- 37:29Contracts and preconditions
- 46:19Precondition violations
- 47:01Safe coding practices
- 49:07Swiss cheese model
- 52:20Static analyzers for safety
- 55:32Fuzz testing
- 57:17Role of contracts
- 59:25Broader safety implications in non-safety-critical software
- 1:02:19Open-source safety libraries
related talks
01h 01mSoftware Security
22mWriting safe and secure code
23mSecure Code, Safe Future: Mastering Security in Critical Software Development
32mDeveloping Open Source for Safety and Security
57mFinding, Managing, Preventing Vulnerabilities: An Automotive Perspective
33mApplicable and Achievable Formal Verification
55mStrong software for a safer future
01h 00mBuilding Safe and Reliable Surgical Robotics with C++