Summary
- What Is It? – Testbench used to train AI to detect security threats in safety-critical real-time systems
- Technologies Used – Java, FreeRTOS, MicroROS, Spike (RISCV-ISA-SIM), FPGA
-
My Accomplishments
- Developed concrete requirements by understanding motivation and goals
- Designed and implemented RTOS resource monitor testbench in software
- Successfully planned and transferred testbench from software to hardware, including physical coprocessor
Motivation
Historically, security has not been a priority in real-time systems, but this is not for lack of need. Real-time systems are becoming more common in safety-critical applications such as self driving cars. In these systems, malicious attacks can have serious, sometimes deadly, consequences. Implementing a security solution for real-time systems is not trivial, however. Embedded systems do not have extra compute power to devote to complex security programs like desktop computers do. A security solution that does not impact performance is desperately needed for these safety critical systems.
Background
- RTOS: A real-time operating system (RTOS) is an operating system for real-time computing applications that processes data and events which have critically defined time constraints.
- Mixed-criticality system: A system in which some tasks are high-criticality (must be completed) and some are low-criticality (acceptable to not finish)
- Mode-switch: When a low-criticality task overruns its deadline, the OS stops execution of low-criticality tasks and only executes high-criticality tasks. This is to ensure that the high-criticality tasks will finish by their deadline.
This research project was based on the paper “Pythia-MCS: Enabling Quarter-Clairvoyance in I/O-Driven Mixed-Criticality Systems.” This paper uses a coprocessor to measure resource usage statistics and I/O volume. With this information, an AI is trained to predict task overruns and mode-switch before they occur. Doing this increases schedualability in the system.
What It Does
Our project extends this idea of overrun prediction by analyzing many different metrics such as resource usage and memory access patterns in real time. Using a coprocessor, our system detects and terminates security threats before they are able to cause damage.
How I Did It
My role in this project was to architect and implement the technology stack we would use. After laying the foundation, my professor and his graduate student would use my setup to test and develop the security coprocessor. I did my part in three phases.
First, I gathered requirements. This was relatively easy to do, because my team already had a good idea of the goals for the project. After a few discussions, we settled on our final requirements. I then used these to design an optimal system. My plan was to first create a proof-of-concept completely in software, as it is easier to iterate with. Once that was promising, we would then transfer it to the physical board.
Second, I created the software testbench. I used Spike, which is an open source, RISCV instruction set architecture simulator. It would simulate the physical instructions that our processor would run. On top of this simulator, I ran FreeRTOS. This is an open source real-time operating system. This is a very common OS used in embedded systems. Lastly, on top of FreeRTOS, I ran microROS, which is a a commonly used open source robotics library. This would allow us to run our test cases easier. We could run microROS operations and then analyze the resource usage. To simulate the coprocessor, I wrote a python program. The program would essentially be a driver for Spike. It would have Spike execute one instruction, then analyze the output. I had the program log things like register values, memory addresses, instruction types, and I/O volume. From here, my team could use my tool to gather and analyze any information they wanted.
Last, I set up the physical board. The hardware we decided on was the Xilinx Zynq-7000. This was perfect for our needs because it has an ARM CPU and FPGA in the same chip. Because they are on the same chip, the FPGA has access to the CPU’s hardware such as registers. The team would use the FPGA to create a coprocessor in hardware, while still being able to quickly iterate. All that was left was to install the software stack onto the board and then design the coprocessor. This is where I handed off my contribution to the others, and allowed them to get started on the analysis.
What I Learned
I learned to develop concreate requirements. Unlike school projects, the requirements were not handed to me. I had to understand the motivation and goals of the project, and come up with requirements that allowed us to achieve the goals. One thing that was important for me was to avoid thinking of implementation. This puts too many constraints on the project and can impede the goals. I learned that it is important to focus on the purpose of the project and leave implementation for later.
I learned how to research a complex, open ended topic to get results. There were many different directions I could have gone with this project, and I ran into many dead ends. It was discouraging but a valuable learning experience. I learned to do preliminary research on a wide area and slowly narrow the scope as I learned more about my options.
Lastly, I learned how to design a complete software system. Figuring out the overall architecture of a project, and how each piece will fit together, is much more challenging that writing a self contained program. I learned to consider how each piece fits together, which is something that came in handy with my Autonomous Delivery Drone project.
Overall, this project taught me a lot about the design and planning that goes into a large complex project.
