# Simulating Cyber-Physical Systems I always find the metaphor of comparing brains to computers or computers to brains quite amusing. Such a comparison is preposterous: computers are, luckily for us, rather stupid. This means they are very easy to fool. The fact they get faster but not necessarily smarter plays in our favor here. For example, imagine a computer controlling a chemical process in some industrial plant. Monitoring a chemical process for sure will need reading temperatures, pressures, flows, etc. For the process to be controlled, the computer needs to read those kinds of variables of interest from the physical environment. This requires, first, converting the real physical quantities into either voltages or currents that the computer will turn into digital. Then, the control system governing the plant will process those converted readings according to some criteria, and it will apply the actuation needed to correct potential deviations from a desired set point. The control criteria usually require monitoring the output variable and comparing it to the set point; the error between those two defines the actuation strategy. This is closed-loop control or feedback control; we spoke about this before. Closed-loop control heavily relies on information flowing back and forth, information that is used for decision-making. Note from the next figure x the division between the computer and the physical boundaries right at the sensor and actuator layer.  The typical building blocks of a generic Cyber-Physical System are: - Comparator:  It provides a signal that is proportional to the difference between the set point and the output to be controlled. - Input: The desired set-point, which is the ultimate objective of the control system; i.e the desired value the control system is expected to reach. The set-point is in the computer domain, can be either analog or digital. - Output: the signal which is the difference between the set point and the measured output. This signal is in the computer domain and can be digital or analog. - Controller: It computes the actuation needed for the output of the plant to reach the set point, within some margin. The controller actuates not only upon the immediate value of the error signal but also on its variations and longtime evolution. The controller lives fully in the computer domain. - Input: signal from the comparator - Output: actuation criteria - Actuator: It effects a physical property according to some control signal. The actuator is a mixed-domain device: part computer domain and part physical domain. - Input: signal command which quantifies the amount and type of actuation. This signal is in the computer domain, and can be analog or digital. - Output: a physical quantity that will ultimately interact with the environment (heat, force, torque, etc.). Actuators are never perfect, and they contain nonlinearities, dead bands, and failure modes galore. - Plant: This is the actual physical process to control. The plant resides fully in the physical domain or physical Universe. - Input: physical variable to alter in order to make the plant transition from an initial state to another state. - Output: the physical quantity to keep under certain desired margins. - Sensor: It observes a physical property and provides a signal proportional to the observation. The sensor is a mixed-domain device: part computer domain and part physical domain. - Input: the physical variable to observe, this is in the physical domain. - Output: a signal which is proportional to the physical variable observed. This is in the computer domain and can be analog or digital. Note that real sensors are far from perfect and they show biases, noises, non-linearities, and multiple types of failure modes. Some sensors are complex subsystems composed of digital embedded computers and software, which means they are susceptible to bugs, bit-flips, resets, etc. ![[Pasted image 20241127121754.png]] > [!Figure] > _A generic closed-loop digital control system (also called a Cyber-Physical System, or CPS)_ A digital control computer produces and consumes numbers; typically, it reads and writes such numbers in memory or processor registers. The numbers the control software needs to consume can come from actual sensor readings, or they could be numbers manually written by us: the computer will not be able to tell the difference. But what if we had a device capable of creating consistent but _bogus_ values in a way we could inject them into the control computer replacing the ones coming from the real sensors? Would the computer be able to recognize they are coming from our device, i.e. artificially created, instead of coming from the real physical process? The answer is: no, it would not be able to tell the difference. And this is the core of what simulation does, in a nutshell. The industry applies this approach for evaluating cyber-physical systems' software before being fielded, therefore any organization dealing with cyber-physical systems (missiles, drones, rockets, cars, chemical plants) needs to do the same. The development process requires adding different bogus numbers generators to inject consistent values in some specific inputs of the system's computers to make the system believe it is in space whilst it is sitting in a clean room. This does not come without challenges though, since it exerts a great deal of pressure on the synthetic simulation [[Modeling The Environment|environment]] for them to be realistic and precise, which can turn them to be extremely complex and hard to maintain. What is more, if only the problem would be replacing those numbers in memory, the issue could be perhaps simpler. The real pain is that control software quickly detaches from the “number producer/consumer” approach and it grows too aware of the underlying architecture, and this dependency becomes problematic when such underlying architecture is not always present up front when the development starts. The number producer/consumer is an oversimplification as well. The way those numbers are refreshed in memory (time delays) can affect the way the control laws work. In short, the control software's “functional coupling” to the physical environment is multi-layered and highly context-dependent. The number of things in the middle between the control laws and the environment is staggering. No wonder it is very cumbersome to transition control software from pure software environments to operative environments. ![[Pasted image 20241127121813.png]] > [!Figure] > _A Cyber-Physical System at its highest level of abstraction. Between the digital control laws and the physical environment, there are multiple layers of things_ The cyber-physical industry invests millions in complex and highly realistic simulation systems, whereas small organizations tend to take a different approach, usually going for lightweight and ultra-low-cost approaches. For instance, "traditional" space simulation environments and ground support equipment (GSE) can take entire rooms in facilities, comprising many racks, industrial computers, and power supplies, imposing considerable logistic challenges during launch campaigns. In contrast, and largely due to budgetary constraints, NewSpace simulation environments run in small, cheap embedded devices, and often fit in a small suitcase (see figure below). ![[Pasted image 20241127121839.png]] > [!Figure] > Simulation environments can run in small embedded computers (credit: "Raspberry Pi" by Flickr user Gijs Peijs and licensed under CC BY 2.0) Just as computers cannot tell if a value in memory represents an actual reading from a physical variable or if it was manually generated by us, software does not really care on top of what platform it is running, provided all dependencies are met (libraries, headers, system calls, etc.). If we manage to meet all those dependencies, we can eventually make a piece of software run just anywhere. This is what is called portability, and somehow the reasoning behind virtualization, containers, etc. A piece of software responsible for controlling a spacecraft runs on very specialized computers, which are robustized for space, mission-critical applications, etc. But, as it is just software, we can manage to make it run on more regular computers, like a cheap laptop. The key here is, again dependencies. There are two levels of dependencies: compile time and runtime. One thing is to fool software to make it compile; a different story is to fool it to make it run and run consistently (i.e. with good numerical results). If only the former is accomplished, most likely it will crash. At compile time, the software is basically expecting pieces of a puzzle such as more source code, compiled libraries, etc. At runtime, the software expects certain values in the right places and for that, it expects to use services from the underlying software layers, such as an operating system (if there is one, this is optional). If any of that is missing, the software will just not run. What is more, for software that runs intensive numerical computations, the underlying architecture can make a big difference: data types, floating point unit precision, data widths, all this needs to be consistent between the final platform (the onboard computer) and the testing environment. When the control system is out in its real environment, functional consistency is provided by the physical world itself.  But if we are to run the control software in a simulated _reality_, then it means we will have to replace the physical world (or the numbers coming from that physical world) with some sort of artificial replacement. This means we will have to interface the control software with other software to provide those services and values. ## Control Loop typical functions The salient algorithmic functions of any digital control system are: - `initAll()`: Sets the system for work. Initializes memory and drivers. - `readSensors()`: This function provides all readings from all sensors present. This includes both digital and analog. - It reaches the sensors through software drivers. - Optionally includes a call to ReportTmy() in order to inform how the reading of the sensors went. - `stepControl()`: This function computes the corrections needed to match a desired set point. It may optionally include a call to ReportTmy() in order to inform how the step of the control loop went, if there were errors, etc. - `writeActuators()`: This function writes the torques and forces calculated from StepControl() into all actuators present. This can be either digital or analog. - It reaches the actuators through drivers. - Optionally includes a call to ReportTmy() in order to inform how the writing of actuators went. If no real sensors or actuators are connected in the loop, such equipment must be simulated with numerical simulators. There are two approaches for this: using the same interfaces as in the real thing or simulated ones. ## Simulation-Centric Design As seen, developing software for digital control or Cyber-Physical Systems involves multiple steps to transition it from purely software environments all the way to the target operative environment. The approach of adding simulation/emulation layers to the control algorithms can only be done properly if it is added as part of the software design process. This means, that to make the control software _fooling_ process more straightforward and reliable, it is key to design it in a way its architecture is aware of the multiple transitions from Type VI (fully software simulation, running on a host workstation) down to Type I (a control system running on its real environment). In other words, from a regular laptop all the way up to space. Moving from one type of simulation scenario to the next one must be as seamless as possible, to reduce the amount of refactoring and changes introduced to the code when transitioning between steps. Ideally, refactoring between simulation stages or types should be zero. The configuration decisions and selections to make the seamless progression of the software scenarios to happen requires a combination of compile time (in most cases) and some runtime modular approaches. For example, conditional compilation is typically used to select which layers the control algorithms will be compiled with. Runtime approaches can also be used, for example using initialization files to select the way the control algorithms will communicate with the rest of the layers. ![[Pasted image 20241127121858.png]] > [!Figure] > Concept Map of a Digital Control System and the Simulation Environment ## Physics and Vehicle Simulation Engines For the control laws of a Cyber-Physical System to converge, the algorithms need to be fed with consistent data, regardless of whether running in a real or synthetic environment.  Control algorithms could not care less. When running in a synthetic environment, this means that the simulated sensors and actuators must be fed with data matching replicas of the physics laws. Otherwise, the control software will quickly detect inconsistent physical behavior as a failure and change its course of action. To simulate the physics, basically, we must create a digital equivalent of a mass orbiting another mass (spacecraft orbiting Earth if we assume an Earth-orbiting mission). This per se is not enough, since we must also allow the mass to rotate around its axes following torques applied. Forces acting on this mass should (even though this might not be a hard requirement) translate the mass in inertial space and allow it to describe a different orbit. We must add perturbations to the orbits described, as it happens in the physical universe. Since orbit perturbations are mostly a product of environmental factors (magnetic field, gravity contribution of other bodies, atmospheric drag, etc.) this means we will have to recreate all those environmental effects and make them affect and alter our mass’s orientation in three axes but also its position in orbit. We need to keep track of the position of the Sun as well, in some frame of reference, for power and thermal analyses. At the same time, a single mass point is usually not enough for the conceptual design of spacecraft. Evaluating antennae, solar panels, and payload orientation is of key importance throughout spacecraft design hence the simulation environment must be able to support creating multi-body structures which can also show both rigid and flexible behavior, to fine tune control laws. It can be already seen that a “physics engine” must be devised. Typically, small organizations jump to grow this capability from scratch. This can take a very long time and a great deal of development effort, and it is at the same time a double-edged sword: if the simulation environment and the system of interest are both under development, this means having two immature systems coupled together. The simulation environment’s first goal is to permit assessment, evaluation, and testing of the system of interest. If both are being developed, the level of confidence in the simulation environment is low hence results found during verification cannot be fully trusted unless such trust in the simulation environment is gained in due time. In short: who verifies the verification environment?