VERSION 0.2 — DRAFT SPECIFICATION

Control, safety, security and AI in one open model.

LUNEX is an open reference model that connects the standards you already use. One base object, 21 sub-models, one shared language — from a single sensor to the AI that adjusts the process. Ready for what comes next.

lunex-composite-model.svg
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 Lunex Object Foundation Safety & Security Cross-cutting Operator Autonomous layer twenty-one sub-models — one composite object model
Why LUNEX

Your plant runs on good standards. They just don't talk to each other.

Control, safety, security, alarms and recipes were each written on their own, and none of them was written for AI. So the plant works, but its description does not. Every project pays for that, in meetings, in translation and in rework. LUNEX answers the question once, in the open.

From separate worlds (control, safety, security, alarms, AI) to one shared model around a single LunexObject
01

One language

Control, safety, security and data teams point at the same objects, with the same names.

02

Traceable change

Every change follows one lifecycle: who, what, why, approved by whom.

03

Connected risk

Access, vulnerabilities, incidents and zones are related, so you can see what a finding touches.

04

Ready for AI

AI works within set limits and never overrules an interlock.

05

No lock-in

Open and free to use under CC BY 4.0. Use it as a tender checklist or an internal standard.

AI model, limits and approval, interlock, process: AI works within limits and interlocks always win
A question worth raising: "Why aren't we looking at LUNEX?"

Let one engineer compare it with how your plant is described today. What fits, what is missing, what would need to change: whatever the outcome, you learn something about your own structure.

01 — What LUNEX is

Layered Unified Namespace for Entities & eXtensibility

Five standards, one gap between them.

PackML describes machine state behavior. ISA-88 describes batch structure. ISA-95 describes the enterprise-to-control hierarchy. IEC 61508/61511 describe functional safety. IEC 62443 describes cybersecurity. ISA-18.2 describes alarm management. Each is authoritative in its own scope — and none of them talk to each other, or to the AI layer that's now a first-class part of the system, not an add-on.

LUNEX doesn't replace any of them. It reuses what each already gets right — SIL, SIF, Security Levels, ISA-18.2's alarm states — and provides the missing part: one object model, from a single sensor up to the closed-loop AI model adjusting the process, built on a single base class throughout.

  • Completeness over minimalism. Process control, safety, security, alarms and AI/data as one connected model, not five bolted together.
  • Reuse before invention. A term is only renamed when it already collides with something else in the model. Sub-model 12 documents every decision.
  • One base class, no exceptions. A pressure sensor and an AI-generated recommendation are both a LunexObject.
  • AI as a structural citizen. Digital twins, prediction, and closed-loop control — governed with the same rigor as a safety interlock.
02 — The specification

Twenty-one sub-models, five bands.

Each band builds on the one before it. Foundation defines the object system; Safety & Security and the cross-cutting band add governed structure on top of it; the operator band adds real-time judgment; the autonomous band adds memory and closed-loop action. Five sub-models — Recipe & Execution, Identity & Access Management, Vulnerability & Patch Management, Security Incident Response, Management of Change — were added to the original sixteen without disturbing any of them.

01–05 Foundation what an object is, where it lives, how it behaves
01
Object / Class Model
Every object in the model — a Sensor, a Valve, even an AI recommendation — is described in the same basic way.
LunexObject (incl. owner), five universal device classes, function-interfaces
object-model.svg
02
Asset Hierarchy / Namespace
Gives every object its own address, like a street address, so it can always be found.
Realm → Domain → Location → Area → Cell → System → Assembly
asset-hierarchy.svg
03
Topology Model
Describes how the Devices inside one Assembly are connected to each other.
Integrated, Point-to-Point, Star, Mesh — plus HA and Cloud flags
topology-model.svg
04
Behavioral / State Model
Defines the states an object can be in — such as Off, Standby or On — and how it moves from one to the other.
the universal state machine behind every object
state-model.svg
05
Recipe & Execution Model
Describes how a product is made (the Recipe) and keeps a record of each time it is made (the RecipeExecution).
ISA-88-derived Recipe/RecipeElement, RecipeExecution reuses the state model directly
recipe-execution-model.svg
06–10 Safety & Security interlocks, network segmentation, identity, patching, incident response
06
Safety
Describes safety functions that can force or block an action — an Interlock — and how reliable they must be.
Interlock as a first-class object, silTarget/silAchieved, machine safety, SafeMotionFunction
safety-model.svg
07
Security Zones & Conduits
Divides the network into protected Zones and defines the Conduits — the only allowed connections between them.
Zone, Conduit — IEC 62443
security-model.svg
08
Identity & Access Management
Describes who or what — a person or a system — is allowed to do which actions on which objects.
Identity, Role, Permission, AccessGrant — who may do what
iam-model.svg
09
Vulnerability & Patch Management
Keeps track of known security weaknesses (Vulnerabilities) and the updates that fix them.
Vulnerability (CVE/CVSS), PatchRecord, governed via ChangeRequest
vulnerability-model.svg
10
Security Incident Response
Describes how a cyber attack, a SecurityIncident, is handled from first detection to full recovery.
SecurityIncident — a peer of Alarm, Detected → ... → Closed
security-incident-model.svg
11–13 Cross-cutting data, naming, and governed change — and the register that keeps it honest
11
Data / AI Layer
Describes how measurements from Devices are collected, given meaning, and copied into a Digital Twin that an AI model can use.
Telemetry Envelope, Context Layer, Digital Twin
data-ai-model.svg
12
Naming & Terminology
Lists every naming choice in the model and why it was made, so each term has only one meaning.
the living register of every naming decision, and why — plus UCUM units
naming-model.svg
13
Management of Change
Makes sure every change is requested, approved and recorded in one standard way (a ChangeRequest).
ChangeRequest, Approval, VersionRecord, and ChangePolicy — one governed workflow
moc-model.svg
14–18 Operator capability status, alarms, guidance, awareness — in real time
14
Collective Status (Rollup)
Combines the state of many objects into one overall status, so you see the worst problem at every level.
severity tiers, worstTier, bubbling up a hierarchy
rollup-model.svg
15
Alarm Management
Describes alarms — what they are and how important each one is — so operators see the most important first.
ISA-18.2 — priority = severity × actionability
alarm-model.svg
16
Alarm Response Guidance
Gives every type of alarm a ready-made plan for what the operator should do.
reusable response procedures, per alarm type
arp-model.svg
17
Scenario Simulation & Operator Guidance
Lets an operator try an action on the Digital Twin first, to see what would happen before doing it for real.
tested on the digital twin before an operator commits
scenario-model.svg
18
Situational Awareness
Gives operators the same kind of overview at every level, with one step straight to the worst problem.
one navigation contract, jumpToWorst()
sa-model.svg
19–21 Autonomous layer memory, prediction, and closed-loop AI — all governed
19
Historian & Analytics
Stores the history of every object, so you can look back at what happened and when.
what the state was, not just what it is — plus VersionRecord baselines
historian-model.svg
20
Predictive Maintenance & Improvement
Warns of what is likely to go wrong (a PredictedEvent) and suggests improvements that a person always has to approve.
internal + external-forecast predictions join the alarm system; changes always need approval
predictive-model.svg
21
Closed-Loop AI Control
Lets an AI model adjust the process, but only within set limits and never overruling an Interlock.
an AI model as an ordinary, bounded ControlUnit
ai-control-model.svg
"Rename a term only when it already carries a conflicting meaning elsewhere in the model, or in an adjacent standard LUNEX must interoperate with. Otherwise, reuse established vocabulary — inventing a new word is not innovation if the old one wasn't actually broken."
— The naming principle, Sub-model 12. Every renamed term in LUNEX is tested against this one sentence.

Early draft. Built to be argued with.

LUNEX is authored by a single contributor and hasn't been reviewed by an independent working group yet. If you work in OT, process safety, or industrial cybersecurity and see something wrong, missing, or overcomplicated — that's more useful right now than agreement.

Read the spec (PDF) View on GitHub