SlideServe
Menu
Préférences
© SlideServe · v2026

Adaptive Cruise Control

MikeCarlo avatar
15 diapositives · 1.4K Views · Nov 11, 2010

Adaptive Cruise Control Ilana Davidi Margaret Stringfellow Herring Paul Wheeler Agenda Hazard Analysis Safety Constraints Partial STPA Completeness Criteria Requirements Changes High-Level Design Intent Specifications Design Limitations Hazard Analysis

Adaptive Cruise Control - slide 1
01 / 15Adaptive Cruise Control
1 / 17

Télécharger la présentation

Adaptive Cruise Control
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. Adaptive Cruise Control Ilana Davidi Margaret Stringfellow Herring Paul Wheeler

  2. Agenda • Hazard Analysis • Safety Constraints • Partial STPA • Completeness Criteria • Requirements Changes • High-Level Design • Intent Specifications • Design Limitations

  3. Hazard Analysis • Constructive way to learn ACC system • Tens of hazards stemmed from three • Rear end car in front • Hit by car in back • Lose vehicle control

  4. Safety Constraints • Matched hazards with safety constraints • Natural outfalling of hazards to safety • Constraints kept simple but precise • Leads to high-level design requirements

  5. Completeness Criteria Example • The system and software must start in a safe state. • Software initial state is “ACC off.” • No direct transitions to hazardous states from “ACC off” • Cannot transition out of “ACC off” state unless • The ignition is turned to the “on” position. • The driver has subsequently pushed the “ACC on” button. • The ACC system passes a self-diagnostic test for system faults • Brakes are not engaged • Speed is greater than 45 mph • ACC then transitions to “ACC standby” state. • There are further conditions to transition from “ACC standby” to “ACC Active”

  6. Requirement Changes Examples • Minimum speed will be 45 mph instead of 25 mph • Alarm will sound during shutdown • Not only in response to driver disengagement from the steering wheel • Set speed is not retained in memory after coast button is pushed • Current speed is used as set speed

  7. Partial STPA • Used control loops to discover states

  8. High-Level Design Distance SP Speed SP Mode Brake SW 1 Actuate Acceleration Actuate Brakes Brake Control Module Engine Power Driver Accelerator Brake Pedal Acceleration Actuate Increasing Speed Of Car Closing Speed Distance Decreasing Speed Of Car Acceleration Distance to Car In Back Brake Lights Warning Decreasing Speed Of Car Distance to Car In Front Radar ACC State Target Speed Brake switch 1&2 Cruise switch Req Target Speed Engine Control Module CAN ACC Break Switch 2 ACC State Brake Request Target Speed Input to Display ACC Input to Display Instrument Cluster Vehicle Speed Brake Actuator Command ACC State

  9. Intent Specification: Level 1

  10. Intent Specification 1: Assumptions • A licensed driver is operating a car with no malfunctions or problems. • The road is smooth and unobstructed. • The road is continuous and does not suddenly terminate. • The ACC system will interface and communicate with five parts of the car • Braking system • Engine • Accelerator • Ignition • Steering Wheel

  11. Intent Specification: Level 2

  12. Intent Specification: Level 3 AND

  13. Design Limitations • Human behavior • Sudden lane changes • Human as cruise control monitor • Auto-off on steering wheel • Clamp • No system redundancy for radar

  14. Lessons Learned • Documenting assumptions & decision reasoning • Generates single mental model across different people • Prevents loss of information over time • Safe systems can be achieved. • Rigorous approach to requirements generation • SpecTRM links hazards, constraints, and assumptions in one document • Provides visibility and traceability • Paul can consult on SpecTRM software • For a price.

  15. Questions?