Skip to content
Examples

Embedded / law enforcement

Traffic Pursuit Unit

In-car speed measurement and video evidence for police pursuits.

Main goal
Produce measurements and video recordings accurate and tamper-evident enough to hold up in court, while keeping every legally approved part inside one separately certifiable unit.
Business domain
Embedded / law enforcement
Size
Hardware/software product · in police cars · successor to an earlier TPU generation
Strategic decisions
  • Legally relevant functions isolated in an exchangeable MeasuringUnit
  • Embedded real-time OS for measuring, Linux for video
  • Integer (fixed-point) arithmetic throughout
Technologies
C++ · RTOS · ARM
Keywords
building-block · runtime-view · quality-scenario · risk · thorough

The Traffic Pursuit Unit (TPU) is a hardware/software system built into police cars. It follows a suspect vehicle, measures its speed profile with high precision, and records video evidence of the violation — accurate enough, and documented well enough, to survive a challenge in court.

Two things make it worth reading as an example. First, it is the only system on this site where the architecture is driven by legal approval: everything a regulatory authority has to certify is deliberately confined to one physically separate MeasuringUnit, so that the rest of the device can be changed without re-certifying it. Second, its authors chose to go deep — the building block view descends to the level of C++ classes and header files, and the runtime view shows the same scenario four times in four different UML notations (sequence, communication, activity, and an extended activity diagram with swim lanes), which is an unusually direct answer to the question of what each notation actually buys you.

Compare the depth here with the other examples on this site: the TPU documentation goes further down than any of them, and its diagrams are hand-drawn in Enterprise Architect rather than generated.

The documentation

  1. 1 Introduction and Goals
  2. 2 Architecture Constraints
  3. 3 Context and Scope
  4. 4 Solution Strategy
  5. 5 Building Block View
  6. 6 Runtime View
  7. 7 Deployment View
  8. 8 Crosscutting Concepts
  9. 9 Architecture Decisions
  10. 10 Quality Requirements
  11. 11 Risks and Technical Debt
  12. 12 Glossary

Start reading →