<!-- argument-hint: [aspect/facet, trustworthiness property, data interoperability, timing/TI class, secure time, GNSS/PTP/NTP, use case, chapter number] -->
NIST Framework for Cyber-Physical Systems (SP 1500-201/202/203)
Source: NIST (US Government work, public domain) | Chapters: 8
When to use
Use this skill to conceptualize, realize, and assure a cyber-physical system or IoT system in a disciplined way: structuring the analysis on the CPS Framework's grid, managing the interacting trustworthiness properties as one cross-property risk problem rather than five silos, making data exchange actually interpretable across domains, treating timing as a first-class architectural and security concern, and deriving requirements from use cases. It is the CPS/IoT counterpart to the broader SE canon (sebok, nasa-npr-7123, dau-se-guidebook) and the security-engineering packs (nist-sse).
Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.
How to Use This Skill
- Without arguments — load the core frameworks below: the aspect × facet grid, cross-property trustworthiness, data interoperability, the timing aspect, and secure/resilient time.
- With a topic — ask about an aspect or facet, a trustworthiness property (e.g. "resilience vs. reliability"), data interoperability (e.g. "canonical model", "identifiers"), a timing-interval class, or secure time (e.g. "GNSS spoofing", "PTP attacks", "holdover").
- With a chapter —
ch02 (the Framework grid), ch04 (cross-property risk), ch05 (data interoperability), ch06 (timing), ch08 (managing and securing time).
Supporting files: glossary.md, patterns.md, cheatsheet.md.
Three volumes, one Framework. Vol 1 (SP 1500-201) defines the CPS Framework (chapters 1–3 here). Vol 2 (SP 1500-202) is the working-group reports — cybersecurity/privacy, data interoperability, timing, and use cases (chapters 4–7). Vol 3 (SP 1500-203) is the Timing Annex (chapter 8). This is a 2017 v1.0 living document, explicitly draft in places.
Core Frameworks & Mental Models
What a CPS is
A cyber-physical system fuses computation, communication, sensing, and actuation onto physical systems to deliver functions whose correctness depends on timing. Its irreducible core is a decision flow plus at least one physical flow — an information flow (digitally measuring physical state) or an action flow (changing it). CPS scale recursively: the same artifact is a device, a system, or a system-of-systems depending on perspective. The genuinely new feature is the intersection of the IT world (data and computation), the OT world (control and actuation), and timing constraints binding them. CPS and IoT overlap heavily; the Framework is meant to apply equally to both.
The CPS Framework — the Aspect × Facet grid
The Framework is an analysis methodology plus shared vocabulary, built by crossing two orthogonal structures:
- Nine aspects — groupings of related concerns: functional, business, human, trustworthiness, timing, data, boundaries, composition, lifecycle. Concerns are the driver of the whole method and are not orthogonal (analyzing trustworthiness forces you to weigh the trustworthiness of timing).
- Three facets — engineering views, each carrying its own activities and artifacts:
- Conceptualization — what the CPS should be/do; produces the CPS model, a rooted tree of traceable properties.
- Realization — how it is built and operated; produces the instance, designs, tests, and trade-offs.
- Assurance — how much confidence, and why; produces the assurance case (claims, evidence, argumentation, estimate of confidence).
Every aspect is examined through every facet. Run the facets as interchangeable modes, not a waterfall — the same grid supports agile, reverse-engineering, service-based, and gap-analysis flows. When several concerns apply at once, the combined requirement is the composition of concerns = set union of the properties each demands. The Framework draws on ISO/IEC/IEEE 42010 (architecture description) and 15288 (life-cycle processes) but does not reproduce their text.
Trustworthiness as cross-property risk
CPS trustworthiness is greater than the sum of trustworthy parts. Treat five top-level properties together — cybersecurity, privacy, safety, reliability, resilience — through one cross-property risk management process, not five silos. Key distinctions and levers:
- Reliability handles risk (known outcome distribution; fault tolerance). Resilience handles uncertainty (unknown distribution, often an adversary; threat tolerance). Most security/privacy challenges live in resilience.
- Treat the risk budget as a common resource every property draws on, allocated by consequence (not split equally). Expect cyber components to consume the largest share.
- Push each protection onto the element type — physical, analog, or cyber — best able to enforce it. Stuxnet defeated five properties engineered in isolation; a physical over-speed interlock would have stopped it regardless of any digital command.
- Cybersecurity is necessary but not sufficient for privacy; security measures can themselves create privacy risk.
Data interoperability
Interoperability is about understanding, not just transport. Climb three rungs above physical connectivity: syntactical (move bytes intact) → semantic (agree on meaning) → contextual (agree on rules of use). A shared canonical model plus well-placed adaptors cuts transformations from ~n(n−1) toward n. Split data into archival vs. real-time (real-time data can expire in transit). Give each datum a unique, persistent, resolvable identifier (keep changeable attributes out of the name). Security = confidentiality / integrity / availability, with availability prioritized in control systems; the trust chain runs all the way down to physical actuation.
Timing as a first-class concern
Timing is the seam where cyber meets physical, and getting it wrong is a correctness failure, not a performance shortfall. Express requirements as bounds on time intervals (TIs) between significant events, and use the weakest class that works:
| TI class | Holds | Use when |
|---|
| Bounded | under a stated max | a deadline only |
| Deterministic | within error of a target, local timescale | a precise relationship must repeat |
| Accurate | deterministic + traceable to UTC/TAI | spatial scale or regulation forces it |
Frequency, phase, and time are distinct; phase and time need signal transport plus delay compensation (so position and time are coupled). Modern CPUs/OSes are not time-aware — explicit time lives in FPGAs/ASICs, time-aware PHYs, and time-triggered architectures. Aim for time-correctness by design: reason in logical time, enforce physical time only at the boundary to physics. At scale, a CPS Time Domain (continuous primary timescale, prefer holdover over discontinuity) plus a CPS Network Manager schedules bounded-latency traffic.
Secure and resilient time
Treat an accurate instant as a measured, attackable supply chain: source, transfer path, quality spec, failure modes, continuity plan. Distinguish denial (jamming — degrade to a safe fallback) from spoofing (counterfeit signal — confident wrong time, the dangerous case). Defenses span GNSS NMA, strong symmetric keys, whole-packet authentication, NTP/PTP-Annex-K/MACsec/IPsec, intrusion detection, and clock-drift correction. Resilience comes from holdover oscillators, integrity monitoring (time-to-alarm, integrity risk, alarm limit), the detect/alarm/fail-over triad, and source diversity (other GNSS, dedicated WANs, SyncE+PTP/White Rabbit, WWVB/WWV, eLORAN). Clock quality is engineered with the clock-error model and the Allan-variance family plus MTIE (which sizes buffers and predicts data slips).
Chapter Index
| # | Vol | Section | Key content |
|---|
| ch01 | 1 | Introduction: what makes CPS different | CPS definition, decision/information/action flows, recursive device/system/SoS, IT-meets-OT-under-a-clock, emergence, composability, the CPS PWG |
| ch02 | 1 | The Framework: facets, aspects, concerns | The aspect × facet grid, nine aspects, three facets, properties, the assurance case, composition of concerns, 42010/15288 base |
| ch03 | 1 | Related standards & applying the Framework | The IoT/timing/security standards landscape (IoT ARM, IEEE P2413, OneM2M, TSN/PTP) and a worked emergency-response use case through the three facets |
| ch04 | 2 | Cybersecurity & privacy (cross-property risk) | Cross-property risk management, five trustworthiness properties, risk vs. uncertainty, the risk budget, physical/analog/cyber co-design, Stuxnet, privacy |
| ch05 | 2 | Data interoperability | Syntactical/semantic/contextual, canonical models & adaptors, identifiers & provenance, data fusion, privacy-by-derivation, Fog, timestamps, CIA with availability first |
| ch06 | 2 | Timing & time-awareness | TI classes (bounded/deterministic/accurate), time domains, the CNM, time-triggered architecture, why CPUs aren't time-aware, secure timing, GNSS jamming/spoofing |
| ch07 | 2 | Use-case analysis method | Two-stage CPS Examples → specific use cases, primitive requirements, the requirement-category form, coverage-gap clustering, worked examples |
| ch08 | 3 | Managing & securing time (Timing Annex) | Clock-error model, Allan/MTIE metrics, time-aware networking standards, two-way transfer & reciprocity, time as a security target, holdover/backups, sector requirements |
Topic Index
- Actuation / trust chain to actuation → ch05
- Allan variance / MTIE / clock-error model → ch08
- Archival vs. real-time data → ch05
- Aspects (the nine) → ch02
- Assurance case / assurance facet → ch02, ch03
- Boundaries / scales / levels (data) → ch05
- Canonical model / adaptors → ch05
- Clock quality / metrology → ch08
- Composability / free composability → ch01
- Composition of concerns → ch02
- Conceptualization / realization / assurance (facets) → ch02
- Cross-property risk management → ch04
- CPS definition / what makes CPS different → ch01
- CPS Network Manager (CNM) → ch06, ch08
- CPS Time Domain → ch06
- Data interoperability (syntactical/semantic/contextual) → ch05
- Data fusion → ch05
- Emergent behavior → ch01
- Facets → ch02
- Fog computing → ch05
- GNSS jamming and spoofing → ch06, ch08
- Holdover → ch06, ch08
- Identifiers / provenance → ch05
- Integrity monitoring (time) → ch08
- IoT / IoT standards → ch01, ch03
- PTP / NTP / IEEE 1588 attacks and defenses → ch06, ch08
- Primitive requirements → ch07
- Privacy → ch04, ch05
- Reciprocity assumption (two-way time transfer) → ch08
- Reliability vs. resilience (risk vs. uncertainty) → ch04
- Risk budget → ch04
- Secure / resilient time → ch06, ch08
- Standards landscape (IoT / timing / security) → ch03
- Stuxnet → ch04
- Synchrophasors / grid timing → ch08
- System of systems (SoS) → ch01
- Time interval classes (bounded / deterministic / accurate) → ch06
- Time-correctness by design → ch06
- Time-triggered architecture → ch06
- Timing aspect → ch06, ch08
- Trustworthiness (five properties) → ch04
- Use-case analysis method → ch07
- Use cases (CPS Examples vs. specific) → ch07
Supporting Files
- glossary.md — key CPS Framework, trustworthiness, data, and timing terms, alphabetical, with chapter references
- patterns.md — reusable patterns (analyze on the grid, run facets as modes, cross-property risk, the interoperability ladder, TI classes, securing time, use-case requirements) with When/How/Trade-offs
- cheatsheet.md — decision rules, the aspect/facet grid, trustworthiness and TI-class tables, threats & defenses for time, tells & smells
Scope & Limits
Covers: the NIST CPS Framework per SP 1500-201 (the aspect × facet grid, nine aspects, three facets, properties, assurance case, composition of concerns); the Vol 2 working-group reports — cross-property cybersecurity/privacy risk, data interoperability, the timing aspect, and the use-case requirements method; and the Vol 3 Timing Annex (clock metrology, time-aware networking, and secure/resilient time). It bridges IT and OT under a clock and complements the broader SE and security packs.
Does not cover in depth: this is a 2017 v1.0 living/draft document — it is explicit that some sections are incomplete and that standards references are exemplary, not prescriptive. It is therefore thin on post-2017 standards evolution (later TSN/DetNet, 5G timing maturation, newer privacy-engineering methodologies), on detailed control catalogs (it points to other NIST work for those), and on deep domain specialization (it gives generic facet activities to be tailored per domain). It names but does not reproduce ISO/IEC/IEEE 42010 and 15288 process text (third-party copyrighted — see se-standards-signpost; for open SE process models use nasa-npr-7123 / dau-se-guidebook), nor the permission-licensed third-party figures in the source (the Beecham M2M map, the ETSI smart-transport illustration, and several vendor/standards-body diagrams). For systems security engineering and cyber-resiliency see nist-sse.
Jurisdiction: US Government public domain work (with named third-party ISO/IEC/IEEE and figure material not reproduced here). The Framework is voluntary guidance and broadly adoptable.