How a device becomes a Diyar solution
Diyar turns a physical device into a certified solution through layered signed documents and firmware-compiled registries, not through custom code written per customer. A signed device profile configures the edge's hardware at boot; a certified verdict engine - a frozen product engine or one of the generic function blocks - decides pass or fail; and a three-document app package computes, offline, exactly what a device is authorized to observe, operate, or actuate. The module walks each of these three layers as they exist in the Diyar edge platform today, closes with one worked solution (ISPM-15) built entirely on that machinery, and states plainly where a capability is proven only against internal example fixtures rather than a field deployment - because that distinction is part of what you need to evaluate the product honestly.
By the end of this module, you will be able to:
- Describe what a signed device profile configures at boot, and explain why the edge refuses to start on an invalid, unsigned, or mismatched profile.
- Explain how the HAL seam (
TempSource/RelayBank/MonotonicClock) lets the same platform drive local hardware or a Modbus (TCP or RTU) field device without touching the safety-critical core. - Explain why the
CERTIFIED_ENGINESregistry, not a valid signature alone, is what lets a new process rule run - and how the generic engines let a genuinely new product ship as pure signed data. - Describe the three documents in a Diyar app package and how their offline intersection (A ∩ B ∩ C) computes a device's effective authority.
- Distinguish deploying an app (signing three documents) from certifying its ability to actuate hazardous output (a firmware release and certification event).