---
creation date: 2024-08-08
modification date: Wednesday 7th August 2024 16:21:36
tags:
  - Writing
---
## Sources
[[Hardware In The Loop Papers]]
# Progress
- [x] Abstract ✅ 2024-08-19
	 - [x] Introduction ✅ 2024-08-14
	 - [x] Background ✅ 2024-08-16
		 - [x] PLC and ICS ✅ 2024-08-14
		 - [x] HiL Simulation ✅ 2024-08-15
		 - [x] Formally Verified Firmware ✅ 2024-08-16
	- [x] Research Approach ✅ 2024-08-19
		- [x] ARCADE ✅ 2024-08-16
		- [x] kOS ✅ 2024-08-19
		- [x] Embedded Controllers ✅ 2024-08-19
	- [x] Challenges and Limitations ✅ 2024-08-19
		- [x] Education of SBD ✅ 2024-08-19
		- [x] Protection Domains ✅ 2024-08-19
		- [x] Upgrade Costs ✅ 2024-08-19
	- [x] Broader Impact ✅ 2024-08-19
		- [x] Cybersecurity of ICS ✅ 2024-08-19
		- [x] Lower formal methods barrier ✅ 2024-08-19
	- [x] Conclusion ✅ 2024-08-19
# What the hell am I talking about?
Topic:  What we're going to do with ARCADE 
### #HeilmeierQuestions
### What are you trying to do? Articulate your objectives using absolutely no jargon.
We are trying to use a control system experimentation suite called ARCADE that connects a simulation of a physical plant to real control hardware. This is called a Hardware-in-the-loop simulation. We want to use this hardware-in-the-loop simulation to do experiments with cybersecurity research of industrial control systems. One of the things we plan to do is integrate a computer kernel that has been rigorously tested with mathematical proofs to be secure from common vulnerabilities, and a newly developed operating system on top of that kernel with similar traits, with a physical plant. We want to build a control program on an embedded controller with this system together to be the first control system built using these tools.

#### ARCADE
The Advanced Reactor Cyber Analysis Development Environment (ARCADE) is an open-sourced control system simulation environment developed by the Sandia National Laboratory [[@maccaroneADVANCEDREACTORCYBER]]. ARCADE helps to evaluate control systems by connecting a simulation of a physical plant built to a control system that can either be virtually emulated or built with genuine programmable logic controllers (PLCs) that may commonly be found in industrial control applications. ARCADE was originally developed with simulations of advanced reactors in mind, but this is not a technical requirement; instead, ARCADE is able to accept any simulation of a plant built in Simulink, and compiled into C code with the Sandia National Laboratory S-Function configured and included [@ FIND CITATION].

The compiled simulation interacts through shared memory with the next piece of ARCADE: the data broker. The data broker has several responsibilities. The data broker first starts the simulation, while configuring the endpoints. The data broker manages the tempo of the compiled simulation while broadcasting the "sensor" values calculated by the simulation. The data broker broadcasts these values using UDP, and any endpoint on the same local network can hear these signals.

The endpoint is the bridge between the data broker and the control system. The endpoint listens for 'sensor' values to be broadcast over UDP, and if configured to accept that value, will pull that value and communicate it to the control system using MODBUS. The PLC or embedded controller at this point will take this new sensor value and perform its programmed operations, and update an output value. The endpoint is constantly scanning for this output update, and when received, will send this signal back to the data broker. The data broker at this point returns the output 'actuator' signal to the simulated plant and the control loop repeats.

Notably, there is little restriction on what sort of simulation or what sort of control structure is required to use ARCADE. The physical simulation can be as comprehensive or as simple as is necessary. There also need not only be a single endpoint, but a researcher is able to use several endpoints that are each possibly connected to several controllers. Speaking of, the control structure is not limited in scope, size, or architecture. Currently, the only requirement of the control structure is that it communicates with the Endpoint using MODBUS relayed over Ethernet. SCADA systems, single PLCs, or even bespoke embedded controllers can all be integrated with ARCADE to perform experiments with detailed plants of real systems.
#### KOs
We want to use KOs as the operating system for the controller. KOs is a secure-by-design operating system that allows developers to create isolated and protected boxes for applications to run (Protected Domains). KOs runs on top of a mathematically verified kernel called seL4 to be assured that this behavior happens as expected. The benefit of this application 'silo-ing' is that we can have multiple processes happening on a single piece of silicon, while being certain that they're unable to interact with one another. They won't be able to access each others memory or communicate unless we explicitly specify that connection should exist.[@FIND CITATION] Effectively, this is a software solution that can mimic air gapping or using a data diode on a system, but existing on the same piece of silicon. We want to use this technology to run control hardware in these protected domains. This way, we can utilize these security guarantees to be able to communicate or monitor a control system without exposing the system to security vulnerabilities that would otherwise be present by having broader communication enabled.

### How is it done today, and what are the limits of current practice?
#### PLCs and Cybersecurity
Today most industrial programming is done using programmable logic controllers. These are computers that are specifically designed for real-time control, and to be capable of executing potentially complex control logic in response to sensor inputs, and create output commands to actuators. These systems use 3 main languages: Ladder Logic, Functional Block Diagrams, and Structured Text. These languages are specified by ==FIND SPEC HERE== and are common across most vendors of programmable logic controllers. 

Common vendors of programmable logic controllers however, are by no means homogeneous. The firmware of these devices as well as the circuitry is proprietary, disabling third-party reviewers from analyzing the security of this firmware without extensive reverse-engineering [@find the source about memory locations], which for the average industrial user, is not a feasible project to undertake. This is problematic: in the current law landscape the onus of cybersecurity falls on the operator, but the operator is unable to inspect the quality of security protections afforded by this proprietary hardware. 

*start talking about KOs*

#### Hardware-in-the-loop simulation
Hardware=in-the-loop (HIL) simulation is a testing paradigm that replaces a physical plant with a simulation, while allowing testing to be performed on genuine control hardware. This control hardware and the signals transmitted to it are generally the real-deal, or otherwise are as faithful of a representation of the control system that would be used on the real plant as possible. This detail is critical. Hardware-in-the-loop simulation is trying to work out the integration of a control program with the actual hardware. This is a different challenge than making the control program itself, and can introduce surprises otherwise.

Hardware in the loop simulation is a popular alternative to testing control systems on an actual plant for several reasons. Testing of control hardware always has the potential for failure--that's why we're testing in the first place. This can be a serious problem when a plant's failures are dangerous. HiL solves this problem because HiL eliminates the potential consequences of a failed control program while still providing the insight of the failure. Second, operating certain plants like a power station or an assembly line for testing are extremely expensive operating and opportunity costs. Time testing on these real systems is effectively downtime, wasting extremely valuable plant online time. HiL is great for this purpose, as with the control signals anticipated as being the same as the actual plant, operators can switch to the new control system tested with HiL without having to have downtime to proof that some controller. HiL testing also has a third major benefit: HiL simulation can allow engineers to do the integration of control code on the system hardware before the actual plant has been created. This is a cost benefit for complex projects where project timelines are more expensive the longer they are. 

Hardware-in-the-loop simulation sees usage in industries where these three categories of danger, expense, and inaccessibility are present. HiL simulation is commonly used in nuclear contexts for example, where the plant itself is often an extreme example of each category, and where construction timelines are already painfully long [@cite vogel plant]. 

Commercial solutions for HiL do exist with two main vendors of off-the-shelf products: SpeedGoat from Mathworks, and the d-Space set of computers. These computers, often called real-time systems, allow experiments to create analog signals that can then be fed to a control system like a PLC while running a simulation of the plant on the computer. These systems are widely used and well documented, but have limitations in that they're closed source which limits their use in cyber security related research. Their being closed source makes them harder to tamper with. A third bespoke option does exist, and that is dedicated server compute platforms to model a specific plant. These options are what are currently used in nuclear engineering contexts to test modern controllers [@find citation].

#### Formal Methods and Control Code

### What is new in your approach and why do you think it will be successful?
We're going to create control programs that operate on hardware and firmware that has proven security guarantees. This is awesome because we can make the case for using embedded controllers in places they haven't been used because of fear of cyber attacks compromising system integrity. This is a big deal and can help us bring critical infrastructure up to speed with where control systems are for less critical systems. This technology has existed for a good bit of time, but has not yet been applied in the context of critical infrastructure. That is our gap. We want to help bring this technology to critical infrastructure and show that we are able to create digital control systems that are resilient to cyber attacks and can be counted on to function in adverse conditions.

We think we're going to be successful because the first usecases of these formally proven components have already been done [[kleinFormallyVerifiedSoftware2018]]. Our goal is to bring this technology that's been demonstrated in a military usecase to one that is more approachable for industrial users. 
### Who cares? If you are successful, what difference will it make?
High-assurance systems in general might really care about this. Current security measures for these systems are very expensive. Air-gapping is not a trivial activity (and not even really a guaranteed approach to security [@FIND CITATION]). Nuclear systems on the other hand, have had a problem that they're stuck on really old technology because of the cybersecurity risks. This technology has a couple of problems. First, maintenence is an issue. Being that a lot of these safety systems use physical hardware to do their control logic, they need to be carefully inspected and kept-up as they age over time. This isn't something that's completely eliminated by using a digital control system instead, but it's much easier to replace a digital controller than it is to replace a relay cabinet (or relay room). Second, the technology that students are coming out of school with are not the technologies that plants have been built with 60 years ago. Modern engineering students are equipped at writing in text based languages and programming controllers such as Arduinos or RaspberryPis. They are significantly less trained with systems that might be solid-state electronic circuit control systems. While nuclear plants have been getting extensions and their service lives have been longer than first expected, we are approaching end-of-life for a significant portion of our nuclear fleet. At the same time, nuclear operators are getting much older [@FIND CITATION]. If we want to be able to build new reactors and keep the nuclear industry healthy, we need to make sure the industry equipment and the skills for new operators are congruent. 

On a different note, there is a benefit in that these digital systems are much easier to reconfigure compared to physical solid-state control systems. If specs change and a nuclear plant using a solid-state system needs to change a setpoint, the result is that a technician needs to meddle with the literal electronic components to effect the change. Changing something like a set point on a digital system is trivial in comparison when it comes to complexity. Digital systems also are able to implement complex control programs more readily compared to solid-state systems. For extremely intricate systems like nuclear power facilities, this is to the benefit of safety and most importantly, capital costs.

In a broader sense, cybersecurity of critical infrastructure and operational technology is a big deal. There are human and environmental costs of accidents that can quite severe. The consequences are not on the same scale of information technology attacks, where data leaks may compromise customer information or result in outages. Instead, physical systems can create severe physical consequences such as loss of life or significant environmental damage.

### What are the risks?
### How much will it cost?
### How long will it take?
### What are the mid-term and final “exams” to check for success?

# How should we lay things out?

A couple ideas from ChatGPT:
## First Crack
### 1. Introduction

- **Context and Importance**: Start with a brief introduction to the significance of cybersecurity in industrial control systems, particularly in critical infrastructure like nuclear power plants. Highlight the growing concern about the security of these systems.
- **Objective**: Clearly state your goal to use ARCADE for cybersecurity research by integrating secure-by-design operating systems like KOs and formally verified kernels like seL4 into control systems. Emphasize the novelty and importance of this approach.

### 2. Background and Related Work

- **Current Practices in Industrial Control Systems**:
    - Discuss the use of PLCs and their associated cybersecurity challenges. Highlight the proprietary nature of these systems and the limitations in security analysis.
    - Explain how Hardware-in-the-Loop (HiL) simulation is currently used, its benefits, and the gaps in existing solutions, particularly concerning cybersecurity research.
- **Introduction to ARCADE**:
    - Describe ARCADE, its components (e.g., simulation, data broker, endpoints), and how it is currently used in control system evaluation.
- **Introduction to KOs and seL4**:
    - Explain the concepts of secure-by-design operating systems (KOs) and mathematically verified kernels (seL4). Discuss their current applications and why they are relevant to your research.

### 3. Proposed Approach

- **Integration of ARCADE with KOs and seL4**:
    - Detail your approach to integrating ARCADE with KOs and seL4 for creating secure control systems. Explain the process and the expected outcomes.
- **Control Program Development**:
    - Describe the plan to develop a control program on an embedded controller using KOs and seL4. Highlight the importance of this being the first control system built using these tools.

### 4. Challenges and Limitations

- **Technical Challenges**:
    - Discuss the technical challenges you anticipate, such as compatibility issues, performance trade-offs, and potential limitations of ARCADE, KOs, and seL4.
- **Security Considerations**:
    - Highlight the specific security challenges that need to be addressed, such as ensuring the integrity of the control program and preventing vulnerabilities in the integrated system.

### 5. Potential Impact

- **Advancement in Cybersecurity**:
    - Discuss how your approach could advance cybersecurity in critical infrastructure. Emphasize the potential to create control systems with proven security guarantees, reducing the risk of cyber attacks.
- **Implications for Critical Infrastructure**:
    - Explore the broader implications, such as easing the adoption of modern, secure control systems in aging nuclear plants and other critical infrastructure. Address the benefits of digital control systems over traditional solid-state systems.

### 6. Conclusion

- **Summary of Contributions**:
    - Summarize the key points of your paper, reiterating the significance of your approach.
- **Future Work**:
    - Suggest potential future research directions, such as further testing and validation, broader applications of your approach, and potential improvements to ARCADE, KOs, and seL4.

### 7. References

- **Citations**:
    - Include all relevant citations to support your work, especially where placeholders are mentioned (e.g., find citations for PLCs, nuclear plant testing, etc.).

## Second Revision
>> Does this fit a vision paper? It certainly isn't broad reaching. It's almost like a proposal

You're correct that the content, as it stands, leans more toward a proposal than a vision paper. Vision papers generally aim to present a broad, forward-looking perspective on a field, identifying trends, challenges, and opportunities while proposing a high-level roadmap for future research or development. They often emphasize the potential impact of a new approach or technology in shaping the future of the field.

To adjust this content to better fit the vision paper format, we can broaden the scope and focus more on the overarching trends and challenges in industrial control system security, emphasizing the transformative potential of integrating secure-by-design technologies like KOs and seL4. The details of the proposed approach would then be presented as part of a broader discussion on the future direction of cybersecurity in critical infrastructure.

Here’s a revised outline that better aligns with the vision paper format:

### 1. Introduction

**Broad Context and Importance**:  
Discuss the growing importance of cybersecurity in industrial control systems, particularly in critical infrastructure like nuclear power plants. Emphasize the challenges posed by the increasing complexity and interconnectedness of these systems.

**Vision for the Future**:  
Introduce the vision of integrating secure-by-design operating systems and mathematically verified kernels into industrial control systems to create a new standard for cybersecurity in critical infrastructure.

### 2. Trends and Challenges in Industrial Control System Security

**Current State of Industrial Control Systems**:

- Discuss the reliance on proprietary, closed-source technologies in industrial control systems, and the challenges this presents for security and verification.
- Highlight the limitations of existing control system architectures, particularly in the context of increasing cyber threats.

**Emerging Trends**:

- Introduce the trend toward open-source, flexible simulation environments like ARCADE for cybersecurity research.
- Discuss the growing interest in secure-by-design operating systems and verified kernels as a response to these security challenges.

### 3. Vision: Integrating Secure Technologies into Industrial Control Systems

**Potential of Secure-by-Design Systems**:

- Explore the potential of operating systems like KOs and verified kernels like seL4 to transform the security landscape of industrial control systems.
- Discuss how these technologies can be integrated into control hardware to create systems that are inherently secure and resilient to cyber attacks.

**Impact on Critical Infrastructure**:

- Envision how these secure technologies could be adopted across various sectors of critical infrastructure, with a focus on nuclear power plants.
- Consider the broader implications for industrial control system design, maintenance, and regulation.

### 4. Proposed Roadmap for Research and Development

**Short-Term Goals**:

- Outline the immediate steps needed to begin integrating secure-by-design systems into industrial control systems, including the development of control programs on embedded controllers.

**Long-Term Vision**:

- Discuss the broader goals of this research, such as establishing new standards for control system security and expanding the use of these technologies in other critical infrastructure domains.

### 5. Broader Implications and Future Directions

**Impact on Cybersecurity Research**:

- Consider how this vision could influence future research in cybersecurity, both within and beyond the field of industrial control systems.

**Opportunities for Collaboration**:

- Discuss potential collaborations with industry, government, and academia to advance this vision and accelerate the adoption of secure technologies in critical infrastructure.

### 6. Conclusion

**Summary of Vision**:

- Reiterate the transformative potential of integrating secure-by-design technologies into industrial control systems.

**Call to Action**:

- Encourage the research community and industry stakeholders to prioritize cybersecurity in industrial control systems and to explore the integration of advanced security technologies.

### 7. References

- Provide citations to key sources that support the discussion of trends, challenges, and emerging technologies.

## Thoughts:
I think the first way has to be the way we go. If we go the second route, it makes Luis' writing harder to fit in and kinda feels like stealing Lance's idea with ARMA. Sure it has ARCADE on top but it is still quite similar

## Proposed Layout
We need to be careful that this doesn't sound too much like a proposal. That isn't what this is. We're trying to illuminate the capabilities we see when our research is done, but we really need to illuminate *why* we need these capabilities. Make good leaning in our background and related work to hint at the reader that there is a problem here with what research exists.
### 1. Introduction
Goals and Outcomes
What are we trying to do?
What capabilities should we have when we complete this work?
### 2. Background and Related Work 
1. PLCs and industrial control systems
	1. PLC heterogeneity, brands what they do
	2. Cyber attacks on these systems, (say gently) push for secure infrastructure
2. Hardware in the loop simulation
	1. What it is, what the context is
	2. current players, MATLAB // dSpace
	3. ARCADE
3. Secure Operating Kernels 
	1. seL4
	2. Littlebird paper
	3. kOS
### 3. Proposed approach
1. ARCADE finally set up at pitt 
2. working with Kry10 and have gotten access to kOS
3. Beagleboards in hand, working on networkign everything
4. What we see as a golden goose. Why our approach is the way to go
### 4. Challenges and Limitations
1. Education of engineers. Blending of CS and control engineering
2. Protection domains and capabilities are a pretty new thing
3. Upgrade costs. Unless seL4 based systems are adopted in control systems, hard to get away from what's currently regulated. IEC standards are well placed
### 5. Broader Impact
 1. Can eliminate a whole lot of cybersecurity by bringing in cyber protections from the get go
 2. Show that control of critical infrastructure can happen with these secure by design systems
### 6. Conclusion

### 7. References
