Before the shell, the asset. The course defines an asset generously: everything that requires a "connection" for an Industry 4.0 solution. That includes machines and their components, supply materials, parts and products, exchanged documents such as drawings and wiring diagrams — and also contracts and orders. An asset is not necessarily a physical thing.
The Asset Administration Shell (AAS) implements Digital Twins. The two definitions matter and are worth quoting:
| Term | Definition (IIC & Plattform I4.0) |
|---|---|
| Digital Twin | A digital representation sufficient to meet the requirements of a set of use cases. |
| Digital representation | Information that represents characteristics and behaviours of an entity (asset). |
Therefore: the Asset Administration Shell is the implementation of the Digital Twin for Industry 4.0.
Six properties define what an AAS does — and notice how many of them are about networking:
The fifth property is the surprising one. A pallet with a QR code has no CPU, no network stack and no security posture — and it can still have an Asset Administration Shell, because the shell lives in the network, not in the thing. This is exactly what makes the AAS usable for the network itself in chapter 11: a P4 switch, a controller, even a table of rules can be modelled as an asset with a shell.
A submodel aggregates information that belongs together. Submodels combine different functional aspects of an Industry 4.0 component, and they come in two kinds:
| Kind | Definition |
|---|---|
| Basic submodels (standardised) | Apply to many assets in the Industry 4.0 world — for example catalogue data of products. |
| Free submodels | Agreed between partners in the value chain for a specific use case. |
An Administration Shell may contain many submodels. The lab deck adds the framing that matters for this course: submodels are the content of the AAS — each represents one aspect of an asset, describing functional, structural or content-related aspects, so that an asset can be represented as a composition of meaningful views. And the reason this matters here is stated bluntly: we do not want a monolithic "network object"; we want separate views for infrastructure, control, and managed behaviour.
Every one of the nine final project challenges (chapter 11) is phrased as "implement a new AAS submodel that…" — enable and disable mirroring, show how many packets were mirrored, count packets per function code, raise an alarm above a threshold, block traffic, activate an encrypted tunnel. The submodel is the unit of work in the project, so being precise about what a submodel is — one aspect of one asset, exposed through a standardised interface — is directly practical.
Eclipse BaSyx uses the Asset Administration Shell as the core technology for digital twins, and it is the implementation used in the lab. Four components:
| Component | Role |
|---|---|
| AAS Registry | Stores and serves AAS Descriptors and the related Submodel Descriptors, enabling discovery of digital twins and their submodels. |
| AAS Repository | Exposes REST APIs to create, read, update and delete AAS instances. |
| Submodel Repository | Does the same for submodels. |
| DataBridge | Connects real or simulated assets to dynamic submodels through protocols such as OPC UA, MQTT and HTTP/REST. |
The architectural claim is that this separates integration, storage, discovery and application access, which supports scalable deployments with multiple repositories and backends. BaSyx also ships an AAS Web UI — the interface through which, in the project work, a user invokes an operation such as "activate the encrypted tunnel for function code 4".
Keep the four BaSyx roles distinct: Registry = discovery (descriptors, "where is it?"), Repository = storage and CRUD (the AAS instances themselves), Submodel Repository = the same for submodels, DataBridge = integration (binding a live asset to a dynamic submodel over OPC UA, MQTT or REST). Being able to say which component you would extend for a given task is the practical version of this question.
ISA/IEC 62443 is the reference cybersecurity standard for the OT world. The slides characterise it along three axes:
| History | Scope | Method |
|---|---|---|
| Initially developed by the International Society of Automation (ISA) and later approved by the IEC in 2021 as a "Horizontal Standard" in the OT sector. | Defines a set of methods and requirements to address cybersecurity issues specific to the OT and IACS/ICS domains. | A "Defense in Depth" model structured around the concepts of Zones and Conduits, implemented through a set of security requirements. |
The standard is a family, organised into four levels. Knowing which level answers which question is the point:
| Level | Documents |
|---|---|
| Level 1 — General | 1-1 Terminology, concepts and models · 1-2 Master glossary of terms and abbreviations · 1-3 System security compliance metrics · 1-4 IACS security lifecycle and use-case |
| Level 2 — Policies & Procedures | 2-1 Requirements for an IACS security management system · 2-2 Security protection rating · 2-3 Patch management in the IACS environment · 2-4 Requirements for IACS service suppliers |
| Level 3 — System | 3-1 Security technologies for IACS · 3-2 Security risk assessment and system design · 3-3 System security requirements and security levels |
| Level 4 — Component | 4-1 Secure product development lifecycle requirements · 4-2 Technical security requirements for IACS components |
The two concepts at the heart of the method:
| Zones | Conduits |
|---|---|
| Represent the different parts of the OT system that require specific protection. Each zone is characterised by an associated security level, determined by the sensitivity of the information and the criticality of the process it manages. | Are the communication paths between different zones. They enable the flow of information between zones and must be designed and managed securely to prevent intrusions, unauthorized access or any other threat. |
Five rules govern how they may be composed, and they are precise enough to be tested:
Here the two halves of the course meet. The argument in the slides is short and complete:
Hence: programmable networking can turn OT security principles into enforceable network behaviour.
Since 62443 organises security around zones (groups of assets with common security needs) and conduits (controlled communication paths), software-defined networking can help implement those boundaries more consistently. The possible applications listed:
The claim: SDN can make zones and conduits more dynamic, consistent, and auditable.
Many OT environments suffer from limited visibility. Programmable networking supports passive traffic collection, flow-level monitoring, asset communication mapping and selective traffic mirroring to security tools — and that telemetry can feed IDS systems (chapter 14), predictive maintenance systems and anomaly detection pipelines.
The section ends with a sentence worth taking literally: programmable networking does not replace OT security principles, it helps enforce them. Segmentation according to Purdue and 62443, observation of process-relevant behaviour, consistent policy across zones and conduits, adaptation with less manual reconfiguration — the principles are the standard's; the network makes them executable.
Andrea Melis's research lecture, From Industry 4.0 to 5.0: IIoT Cybersecurity Challenges, takes the four problems of chapter 9 and attacks them in four parts — legacy, hardening, infrastructure, testing — all on the network side.
The context first. IIoT enables real-time data exchange and advanced analytics in industries, characterised by data-driven decision-making, enhanced operational efficiency and interconnected devices, built on sensors, actuators, smart devices and smart gateways in hardware; cloud, on-premise AI and data aggregators in software; and real-time monitoring for predictive maintenance and cybersecurity as process. The scale: by 2030, 75 billion devices connected; the IIoT market to exceed $1.1 trillion by 2028. The cost: 91% of organizations reported at least one cyber incident or breach last year (Deloitte), with an average data breach cost of $4.35M (IBM). And the trend: supply chain attacks increased by 300% in 2024 (ENISA).
Industrial devices communicate via a mix of proprietary and standard protocols — Modbus, DNP3, CAN, MQTT. Secure versions rely on TLS and certificate management, which is difficult to use on legacy devices, difficult to update on older devices, and difficult for certificate management. Even where Modbus security exists, what are the chances that all the Modbus devices in an ICS network support it? And a PKI is still needed to manage the certificates.
The proposal has three steps:
The reference is L. Rinieri, A. Iacobelli, A. Al Sadi, A. Melis, F. Callegati, M. Prandini, In-Network Encryption for Secure Industrial Control Systems Communications, IEEE NetSoft 2024.
The motivating problem is that traditional monitoring is complex and resource inefficient: limited network visibility with fixed node-level configurations, and expensive, time-consuming offline analysis of traffic. P4 allows you to code networking behaviour directly inside the network, with four advantages: speed (in-line processing of traffic), more visibility and configurability, usefulness for in-depth network analysis, and a custom, high-level means of communication with the network manager.
More specifically, P4 lets you express compact data structures to track network behaviours on the data plane, design simple network protocols to exchange information between nodes, aggregate data directly on the network to produce slim reports, and keep in-memory state.
| Benefits | Challenges |
|---|---|
|
|
The evaluation, in a virtualized testbed, measured overall performance, encryption/decryption overhead and connection establishment time: roughly 10,000 read and write register function calls comparing traditional Modbus, in-network encryption and Modbus TLS; average packet processing and dequeuing times for the overhead; and over 10,000 connection attempts comparing the Modbus connection time (the TCP three-way handshake), the Modbus TLS establishment time, and a connection with Diffie-Hellman.
It is possible to exploit P4 programmable switches to provide secure communication in ICS while respecting the real-time constraints of these environments. The results show the in-network solution performs better than Modbus TLS and almost in line with unencrypted Modbus. Sacrificing end-to-end encryption provides value in scenarios characterised by low-computing-power devices unable to perform TLS cryptographic primitives, and by legacy devices that do not support the Modbus security specification.
The second research part moves from the wire to the controller. ICS are responsible for production plants and critical infrastructures, and process disruption may cause harm to human beings, monetary loss and damage to properties and the environment — therefore security, in addition to safety, is of paramount importance.
Since sensors and actuators are controlled by PLCs, the security of an ICS is strictly related to the security of its PLCs, which have been targets since Stuxnet. Evolving after Stuxnet, a broader category of attacks focuses on manipulating the logic circuits of PLCs: Ladder Logic Bombs (LLBs).
An LLB is malware intended to disrupt the normal operations of a PLC by waiting for specific trigger signals to activate malicious behaviour — hence "bomb". The research focuses in particular on stealthy LLBs: those that are hard to detect by human operators manually validating the program running in the PLC. The canonical example is a Denial of Service LLB: insert a logic bomb containing an infinite loop into a Function or Function Block, since its execution would make the PLC unusable.
Recall the scan cycle from chapter 9: read inputs, execute logic, update outputs, repeat. A loop that never terminates freezes phase 2, so phase 3 never runs and the actuators are never updated. The PLC does not crash — it simply stops keeping its promises to the physical process, which is worse, because interlocks and control loops silently stop working.
Is it possible to detect Ladder Logic Bombs hidden in PLC Ladder Diagram control programs by employing formal verification techniques? The answer is an architecture of three components — parser, simulator, model checker (Iacobelli, Rinieri, Melis, Al Sadi, Prandini, Callegati, IEEE ICPS 2024):
A dataset of 60 PLC control programs — 30 benign and 30 containing a DoS LLB — was built, modelled after a water tank filling system and released publicly. Four attack vectors were identified, each inserting the logic bomb within a different Function Block defined by the attacker:
From these vectors, 26 variations were derived, principally of two types: the Function Block containing the malicious code is moved to different positions in the LD code or linked in different ways to LD components; or it is substituted with another similar Function Block with the same purpose.
| Dataset | Accuracy | Precision | Recall | F1 Score |
|---|---|---|---|---|
| Malicious programs | 100% | 100% | 100% | 100% |
| All programs | 97% | 94% | 100% | 97% |
Limitations, stated honestly: the testing relied heavily on the authors' own dataset, and there are no other datasets in the literature for comparison; the architecture may not comprehensively capture emerging threats or LLBs in different scenarios. The proposed remedy is to highlight to the scientific community the importance of building PLC control program datasets taken from real use cases. Future work: expand the dataset with other LLB types and additional physical processes such as chemical dosing or smart grid (almost done); add static analysis through control flow graphs (CFG) to detect the trigger signals that activate a bomb; and investigate how machine learning algorithms perform in LLB detection.
Read the two result rows carefully. Recall is 100% in both — no malicious program was missed. Precision drops to 94% on the full dataset, meaning a few benign programs were flagged. In an OT context that trade-off is the right one: a false alarm costs an engineer's afternoon; a missed logic bomb costs the plant.
Two research challenges are posed: certificate management in industrial scenarios — how to establish a PKI compliant with industrial real-time constraints and legacy devices? — and secure provisioning of industrial devices, the process through which devices are transformed from their manufacturing state to a configured state that enables using them functionally and securely.
Recall from chapter 9 that an OPC UA client and server perform a four-step security handshake, authenticating with their OPC UA API certificates, which are mutually exchanged and verified, and that each device maintains a Trust List of certificates it trusts. The uncomfortable practical fact quoted in the lecture: considering OPC UA, the most "secure" way to bootstrap that trust today is to use an out-of-band channel in the form of QR codes (Erba, Müller, Tippenhauer, Workshop on CPS & IoT Security and Privacy).
The proposal combines blockchain and P4 switches:
Provisioning then reduces to two steps: connect the new device to the network, and have the system administrator sign the new device's certificate and push it to IOTA.
The third research part starts from context: ICS are heterogeneous systems; Industry 4.0 introduced smart network devices for IoT and maintenance; Industry 5.0 aims to exploit that functionality to create more complex systems. Three challenges follow: unified network policies and intents, security-by-design network and infrastructure, and adaptable, dynamic and agnostic solutions.
An Intent Based Network is a network technology concept that aims to apply a deeper level of intelligence and intended state to replace the manual processes of configuring networks and reacting to network issues. The worked example is regulatory and concrete:
The research statement is "Generative (Not Neural) Networks: Merging Gap Between Intent Based and LLM Agent Based Networks", and the lecture builds the necessary LLM background: fine-tuning (adapting some or all parameters of a pretrained model to new data) and parameter-efficient fine-tuning (PEFT), which selects a subset of parameters to update and freezes the rest, because full fine-tuning of huge LLMs is expensive in processing power, memory and time; RAG, used here to generate PLC code from the OSCAT IEC 61131-3 library through a Document Loader, a Document Chunker and a Text Embedder that encodes chunks as vectors so relatedness becomes a distance; and in-context learning (zero-shot, one-shot, few-shot), motivated by the observation that humans do not require large supervised datasets and that very large pre-trained models appear to learn by example without gradient steps.
An LLM agent is then described as four components:
A large language model with general-purpose capabilities serves as the main brain, agent module or coordinator of the system, activated using a prompt template containing important details about how the agent will operate and the tools it has access to.
Without feedback: the planning module breaks the request into steps or subtasks, so the agent can reason better and reliably find a solution; popular decomposition techniques are Chain of Thought (single-path reasoning) and Tree of Thoughts (multi-path reasoning). With feedback: a mechanism lets the model iteratively reflect and refine the plan based on past actions and observations, correcting mistakes — ReAct and Reflexion. Feedback matters in complex real-world environments where trial and error is key.
Stores the agent's internal logs — past thoughts, actions and observations, including all interactions with the user. Short-term memory: context about the current situation, realised by in-context learning, short and finite because of the context window. Long-term memory: past behaviours and thoughts retained over an extended period, usually an external vector store with fast, scalable retrieval.
A set of tools and APIs that enable the LLM agent to interact with external environments. Evaluation of such agents is itself hard: human annotation, a Turing test comparing agent and human results, designed metrics (task success, human similarity, efficiency), protocols (real-world simulation, social evaluation, multi-task evaluation, software testing) and benchmarks.
The proposed system takes a high-level intent, performs intent decomposition with an LLM as controller (e.g. HuggingGPT), and dispatches to a collection of available AI agents: an Edge-Cloud Continuum Service Deployment agent (using MORL), an Optical Network Config agent (emitting JSON config), and a P4 Switch Code Gen agent (feeding a P4 compiler). Agent selection follows either the HuggingGPT style, where the LLM directly chooses which patterns to use, or a Chain-of-Thought approach inspired by Android's Intent model: the LLM produces a list of actions with an identifier of the functionality needed (Android MediaStore.ACTION_VIDEO_CAPTURE style), and agents declare at registration time which features they can handle (Android intent-filter style).
To bridge the gap between high-level intent and low-level artifact, the lecture proposes a choreographic language such as Choral. Choreographic Programming is a recent paradigm for concurrent and distributed software in which developers write a coordination plan — a choreography — for a set of distributed roles (abstractions of communicating processes), which a compiler automatically translates into an executable program for each role (Giallorenzo, Mauro, Melis, Montesi, Peressotti, Prandini, Choreography-Defined Networks: A Case Study on DoS Mitigation, ICSOC 2024).
Applications span three domains: consumer (edge computing, IIoT); enterprise (adaptable and dynamic network configurations for active defense, standard-related network applications, network-policy enforcement, human-in-the-loop, legacy); and military (tactical distributed and cloud networks, multi-domain communications, network XaaS).
The fourth part answers the question every previous section raises: how do you test any of this without breaking a plant? With a cyber range, whose goals are:
The architecture divides the scenario according to the classical scheme: the IT segment (PCs, servers, printers) separated from the OT segment (sensors, PLCs, industrial gateways). Its main physical components are a RevPi for industrial controller device emulation, a programmable switch for segmentation and advanced mirroring, a Jetson Nano for the ML algorithm, and a server for IT traffic.
The hardware-in-the-loop test case uses a device with screw connectors for the 1Wire bus and one 10 Mbps Ethernet port, supporting HTTP GET, SNMP TRAP, Modbus TCP, TCP and MQTT. The questions asked of a newly-arrived temperature sensor with Modbus are exactly the ones a plant engineer cannot answer without a range: does it support encryption, and if so should it be integrated with an internal PKI? Can the network configuration be affected by this new device? Is the device vulnerable? Are the new settings vulnerable? Hence the need for a testing framework that is reliable and "offline".
A neural network was trained on the XIIoTID dataset (Connectivity and Device Agnostic Intrusion Dataset for Industrial Internet of Things). The model consisted of multiple dense layers with ReLU activations, dropout layers for regularization, and a softmax output layer; trained for 10 epochs, achieving a test accuracy of approximately 96.4%.
To evaluate it, the OMNeT simulation environment was used to generate a dataset capturing more than 1000 normal and anomalous traffic patterns from simulated IIoT scenarios. The results indicate that the pre-trained model performs well on both the original and the simulated datasets, and the ROC curve confirms its robustness in distinguishing benign from malicious traffic.
| Benefits | Challenges |
|---|---|
|
|
The honesty of the challenges column is the most professionally useful thing in this lecture. "Wannabe device and protocol agnostic, but…" is what agnosticism always looks like in practice, and "automatic tests are not always effective" is the reason the cyber range includes hardware in the loop rather than only simulation.
An asset is everything that requires a "connection" for an Industry 4.0 solution: machines and components, supply materials, parts and products, exchanged documents such as drawings and wiring diagrams, contracts and orders. The AAS is the implementation of the Digital Twin for Industry 4.0 — a Digital Twin being a digital representation sufficient to meet the requirements of a set of use cases.
It integrates the asset into Industry 4.0 communication; is addressable in the network and identifies the asset unambiguously; provides controlled access to all information of the asset; is the standardised and secure communication interface; can integrate intelligent and non-intelligent assets (e.g. via barcodes or QR codes); and represents the entire life cycle of products, devices, machines and plants.
A submodel aggregates information that belongs together, combining different functional aspects of an Industry 4.0 component; submodels are the content of the AAS, each representing one aspect, so an asset becomes a composition of meaningful views. Basic submodels are standardised and apply to many assets (e.g. product catalogue data); free submodels are agreed between partners in the value chain for a specific use case. One shell may contain many submodels.
AAS Registry — stores and serves AAS and Submodel Descriptors, enabling discovery. AAS Repository — REST APIs to create, read, update, delete AAS instances. Submodel Repository — the same for submodels. DataBridge — connects real or simulated assets to dynamic submodels via OPC UA, MQTT and HTTP/REST. Together they separate integration, storage, discovery and application access.
History: developed by ISA, approved by the IEC in 2021 as a "Horizontal Standard" for OT. Scope: methods and requirements for cybersecurity issues specific to OT and IACS/ICS. Method: a Defense in Depth model structured around Zones and Conduits and implemented through security requirements. Its four levels cover General (1-x), Policies & Procedures (2-x), System (3-x) and Component (4-x).
Zones are parts of the OT system requiring specific protection, each with a security level determined by information sensitivity and process criticality. Conduits are the communication paths between zones, which must be securely designed and managed. Rules: (1) a zone may have sub-zones; (2) a conduit cannot have sub-conduits; (3) a zone may connect to multiple conduits and its systems may use one or more; (4) a conduit internal to a zone cannot interact with other zones; (5) a conduit may connect two zones and no more.
Because OT security is largely an architectural problem: industrial environments need segmentation, controlled communications, continuous visibility and minimal operational disruption, while traditional static configurations are hard to scale and maintain. Programmable networking enables automated, policy-driven enforcement — it can isolate cells, restrict east-west traffic, enforce approved inter-zone flows and adapt policies when assets change, making zones and conduits more dynamic, consistent and auditable. It does not replace OT security principles; it helps enforce them.
(1) Modbus client and server are directly connected to P4 programmable switches; (2) symmetric AES encryption is realized in the data plane when the controller installs specific rules; (3) keys are shared via the controllers. Benefits: encryption activated by a new flow rule, reduced non-encrypted surface, device agnostic, multi-tunnel, plus general P4 benefits. Challenges: not a full end-to-end encryption layer, protocol dependent, encryption switch oriented.
Measured in a virtualized testbed over ~10,000 read/write register calls and ~10,000 connection attempts, the in-network solution performs better than Modbus TLS and almost in line with unencrypted Modbus, while respecting real-time constraints. Sacrificing end-to-end encryption is worthwhile for low-computing-power devices that cannot perform TLS primitives and legacy devices that do not support the Modbus security specification.
Malware that disrupts normal PLC operation by waiting for specific trigger signals to activate malicious behaviour; stealthy LLBs are hard for human operators to detect when manually validating the program. A DoS LLB inserts an infinite loop into a Function or Function Block: because the scan cycle must read inputs, execute logic and update outputs, a non-terminating loop freezes execution so outputs are never updated — the PLC becomes unusable without visibly crashing.
Three components: a parser (reads PLCopen XML, converts LD components / ST instructions into objects and then into a mathematical model of Intrepid instructions), a simulator (computes output values at each time step), and a model checker (Intrepid, based on backward reachability, checking whether defined requirements are reachable or unreachable). On a public dataset of 60 programs (30 benign, 30 with a DoS LLB, modelled on a water tank filling system): 100% across all metrics on malicious programs, and 97% accuracy, 94% precision, 100% recall, 97% F1 on all programs.
Certificate management and secure provisioning in industrial scenarios, where a PKI must be compliant with real-time constraints and legacy devices — and where the current best practice for OPC UA trust bootstrapping is an out-of-band QR code. PKIOTA combines blockchain and P4: the IOTA blockchain acts as CA, and the controller installs rules on P4 switches to allow only connections with trusted certificates. Its four layers are Device (OPC UA clients/servers), Data Plane (P4 switches doing in-network certificate validation), IOTA Clients (middleware), and IOTA (immutable ledger for issuance and revocation). Provisioning becomes: connect the device, and have the admin sign its certificate and push it to IOTA.
An intent-based network applies a deeper level of intelligence and intended state to replace manual configuration and reactive troubleshooting: an intent is translated into policies, interpreted into infrastructure-as-code, and deployed onto an SDN appliance. An LLM agent has four components: agent/brain (the LLM coordinator activated by a prompt template), planning (task decomposition — Chain of Thought, Tree of Thoughts — with or without feedback via ReAct/Reflexion), memory (short-term via in-context learning, long-term via an external vector store) and tools (APIs to interact with external environments).
Goals: analyze replicated data traffic, test hardware-in-the-loop devices, stress defense mechanisms such as IDS rules, and replicate specific attacks safely. It separates IT from OT segments and uses a RevPi (controller emulation), a programmable switch (segmentation and advanced mirroring), a Jetson Nano (ML) and a server (IT traffic). A dense neural network with ReLU, dropout and softmax, trained 10 epochs on XIIoTID, reached about 96.4% test accuracy, and performed well on 1000+ normal and anomalous patterns generated in OMNeT, with the ROC curve confirming robustness.