# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 3 ROS Primer
### Basic Concepts  
From the software organization and communication standpoint, an ROS system is composed of a set of cooperating processes structured in a _computation graph_. Within the graph, each _node_ is a process responsible for a portion of data processing. Links in the graph represent communication paths among nodes. Since ROS encourages fine-grained modularity, a typical ROS system consists of multiple nodes. Nodes are written with the help of a client library that depends on the programming language being used. For instance, nodes written in Python (both version 2 and 3 are supported) use the rospy library. The basic unit of communication among nodes is the _message_, a simple data structure comprising typed fields. ROS supports the most common primitive types, like Booleans, integers, and floating-point values. They can be placed into arrays and structures, which can then be nested arbitrarily. The main ROS message transport system is based on the publisher-subscriber paradigm. In this approach, nodes send out data of possible interest to others by publishing messages to a certain _topic_. Interested nodes subscribe to the topic to receive them. Each topic supports a single message type and has a unique _name_ in the system, which both publishers and subscribers use to refer to it. There may be multiple publishers and subscribers to the same topic, and an individual node may publish and subscribe to multiple topics, thus establishing a many-to-many communication relationship. To better accommodate one-to-one, synchronous, request-reply interactions between nodes, ROS also supports the concept of _service_. A service has a unique name, like a topic, and has two message structures associated to it, one for requests and one for replies. A server node that offers a service registers it under a unique name. Client nodes locate a server by looking up the name of the service it offers, send a request message to it, and wait for a reply. From the programmer's perspective, this kind of interaction is usually seen as a Remote Procedure Call (RPC). In both cases, the ability to resolve a name and determine which nodes are related to it as publishers-subscribers of a topic or as service provider is crucial, also considering that ROS nodes are not a priori aware of each other's existence and position in the computation graph. This role is fulfilled by the ROS _master_, whose identity is expressed by a Uniform Resource Identifier (URI) and is assumed to be well known to all other nodes. The master acts as a centralized store of registration information about topics and services for other nodes to use. For instance, publishers of a certain topic contact the master to inform it of their presence. The master keeps the list of publishers of a certain topic up to date so that subscribers can acquire this information as needed. The master may also call nodes back when the registration information changes, thus enabling nodes to adapt to a dynamically changing communication graph topology. It is work noting that, although the ROS master plays the role of a _broker_, unlike other kinds of brokers, it is not directly involved in publisher-subscriber data transfer. In order to do that, nodes will indeed make use of the information they acquired from the master but will then use it to establish a direct peer-to-peer data connection. The last ROS component to be discussed here is the _parameter server_. It acts as a centralized store of \((\text{key},\text{data})\) pairs that all ROS nodes may obtain and set at will. In the pair, key uniquely identifies a certain parameter and data is its value. Parameters are often used to store settings for an ROS application as a whole and make them globally accessible. Although the parameter server was originally meant to be used sparingly and mostly during initialization, to retrieve parameters that are not going to change while the system is operational, ROS noetic actually calls it much more frequently as better explained in Section 6.4.