# A C-Based Framework for Low-Cost Real-Time Embedded Systems
## 3 System Architecture  
Figure 1 depicts the typical system architecture an Rtfw system is built upon. With respect to [9], the figure has been redrawn to show that Rtfw supports multiple real-time and best-effort buses and networks, and reflects the complete redesign of the Internet interface model. As shown in the figure, the main _controller card_ that hosts the Rtfw-based firmware is a microprocessor-based real-time embedded system, possibly connected to some local devices through an on-chip or on-board bus. Given that embedded system design has been shifting from a centralized towards a distributed I/O paradigm [40], Rtfw also supports custom or commercial _remote I/O cards_, usually not based on Rtfw, which the control system can reach via a serial RS-485 multidrop line, a CAN [39] bus, or an Ethernet network. CAN-based communication may be based on the Modbus-CAN protocol [41] or CANopen [42], while Modbus-TCP [43] is suitable for Ethernet. Legacy devices may be handled by means of Modbus-RTU [44] on RS-485. All these protocols are fully supported by multiple, readily available open and closed-source libraries, like [45, 46, 47].  
An additional feature of Rtfw, shown in the bottom-right part of the figure, is the ability to grant access to a subset of its internal state to other agents and support Internet access. This feature is extremely important for key functionality--such as data logging, supervision, and firmware upgrades--and has been implemented by means of proxies and the Internet access mechanism discussed in Sections 4.5 and 7, respectively. Finally, user access is made possible by means of a local or Internet-based user interface (UI). Both share relevant information with the real-time portion of the system.  
Internet communication typically takes place through a dedicated, best-effort network, as shown in Figure 1. Although RTFw currently supports only Ethernet-based Internet access, other interfaces such as WiFi, Bluetooth, or LoRaWAN may serve the same purpose, provided they are supported by the underlying protocol stacks on which RTFw is based. However, on systems with less demanding bandwidth requirements and real-time constraints, physically segregating real-time and best-effort traffic into their own network segment may be unnecessary. For instance, a single Ethernet segment may profitably be used for both, with the assistance of a prioritization mechanism like the 8802-1Q Priority Code Point (PCP) of VLAN-tagged frames [48]. The use of Time Sensitive Networks has been ruled out because their complexity would probably make them unsuitable for the class of embedded systems targeted by RTFw.  
As a real-time execution model, RTFw implements a _cyclic executive_[49] augmented with a mechanism to react to asynchronous events generated by remote I/O devices, thus making both time-driven and event-driven programming possible, both will be discussed in more detail in Sections 4.1 and 5, respectively. Even though more sophisticated execution models have been proposed in the past [50], the cyclic executive has the advantage of being well-adapted to the cyclic, master-slave communication of Modbus [51] and the time-driven Protocol Data Objects (PDOs) of CANopen [42]. At the same time, asynchronous event reaction accommodates event-driven CANopen PDOs.  
To make RTFw more portable and flexible [52], its execution model has been layered on top of a general task-based system, coordinated by the FreeRTOS open-source RTOS [36]. The underlying RTOS is also useful, for instance, to seamlessly integrate a multi-task UI while keeping it separate from the real-time control system from the logical and timing point of view. Moreover, most of the third-party firmware components used by RTFw and mentioned previously are likely to require, or highly benefit from, the availability of RTOS services and multitasking.