Which Lines Of Code Encapsulates The State Machine's Data?

MQTT-Reactive

MQTT-Reactive is a MQTT v3.i.i customer derived from LiamBindle'southward MQTT-C library. The aim of MQTT-Reactive is to provide a portable and not-blocking MQTT client written in C in order to be used in reactive embedded systems.

Many embedded systems are reactive, i.east. they react to internal or external events. Once these reactions are completed, the software goes dorsum to await for the next event. That is why effect-driven systems are alternatively called reactive systems. The event-driven programming or but reactive programming is i of the about suitable programming paradigms to achieve a flexible, predictable and maintainable software for reactive systems. In this paradigm the menstruation of the program is determined by events. Oft, the reactive software's structure is composed of several concurrent units, equally known as active objects, which look and process dissimilar kinds of events. Each agile object owns a thread of control and an event queue through which it processes its incoming events. In reactive systems, the agile objects have typically state-based behavior defined in a statechart.

In lodge to explore how to utilize the MQTT-Reactive library in a reactive system with multiple and concurrent tasks and using both a state machine and the outcome-driven paradigm, nosotros use an IoT device as an instance.

The idea of using MQTT protocol was born while an IoT device was being adult for a railway visitor. This device was a clear reactive system that was able to:

detect and shop changes of several digital inputs
acquire, filter and store several analog signals
send stored information to a remote server periodically
transport and receive data through MQTT protocol over GSM network

MQTT was chosen because it is a lightweight publisher-subscriber-based messaging protocol that is commonly used in IoT and networking applications where high-latency and depression information-charge per unit links are expected such as the GSM networks.

The MQTT capability for the mentioned IoT device was accomplished by using a modified version of LiamBindle's MQTT-C. Since the software of that device had been designed every bit a reactive software, MQTT-C had to exist modified to communicate it with the rest of the arrangement by exchanging asynchronous events. These events were used for receiving and sending traffic over the network as well as for connecting and publishing sensitive information to a server. The resulting software library was called MQTT-Reactive.

MQTT-Reactive was used through a state automobile as shown in Effigy one, which models the basic behavior of a MQTT-Reactive client. Information technology was an agile object called MqttMgr (MQTT Director), which provided strict encapsulation of the MQTT-Reactive code and it was the merely entity allowed to call whatever MQTT-Reactive function or access MQTT-Reactive data. The state machine actions in Figure 1 demonstrate how the MQTT-Reactive library could be used from a state motorcar. Even though the C linguistic communication was used as the activity language in Figure 1, any reckoner or formal linguistic communication tin be used.

Figure 1. State machine of a MQTT-Reactive client (Source: VortexMakes)

The country machine in Figure i starts in the WaitingForNetConnection state. After a network connection is established to a server, the WaitingForNetConnection receives the Activate upshot, and and then the state machine transitions to WaitingForSync state. Simply in this state tin can the state machine phase MQTT messages to be sent to the banker such as CONNECT or PUBLISH through the Connect and Publish events respectively. The Sync state uses an UML'southward special machinery for deferring the Publish result that is specified by the defer keyword included in the internal compartment of the Sync country. If the Publish issue occurs when Sync is the electric current state, it will be saved (deferred) for hereafter processing until the SM enters in a state in which the Publish event is non in its deferred event list such as WaitingForSync or WaitingForNetConnection. Upon entry to such states, the state machine will automatically recall whatsoever saved Publish event and will then either eat or discard this outcome according to the transition target country.

Every SyncTime milliseconds the state automobile transitions to the Sync composite state, which does the actual sending and receiving of traffic from the network by posting Receive and Send events to the network manager. Information technology is a concurrent entity that deals with network issues. Even though the introduced MqttMgr SM just supports the CONNECT and PUBLISH packets, it could support the SUBSCRIBE packet with rather simple changes.

The post-obit table summarizes the involved events in the shown land machine.

Event	Parameter Proper name	Parameter Type
Agile	-	-
Deactive	-	-
NetDisconnected	-	-
Connect	clientId	char [23]
Connect	keepAlive	uint16_t
Publish	data	uint8_t [2048]
Publish	size	int
Publish	topic	char [twenty]
Publish	qos	uint8_t
ConnAccepted	-	-
ConnRefused	code	MQTTConnackReturnCode
Receive	-	-
Received	data	uint8_t [1024]
Received	size	int
Send	data	uint8_t [2048]
Send	size	int
Sent	-	-
ReceiveFail	-	-
SendFail	-	-

The state machine actions access to the parameters of the consumed event by using the params keyword. For example, in the following transition, the Connect outcome carries 2 parameters, clientId and keepAlive, whose values are used to update the corresponding MqttMgr object'southward attributes:

              Connect(clientId, keepAlive)/         me->clientId = params->clientId;         me->keepAlive = params->keepAlive;         me->operRes = mqtt_connect(&me->client, me->clientId,              Zip,              Aught,              0,              NULL,              NULL,              0, me->keepAlive);

In this example, the Connect(clientId, keepAlive) event is the trigger of the transition and the mqtt_connect() call is function of the activity that is executed equally a result. In other words, when the MqttMgr object receives a Connect(clientId, keepAlive) event with the parameters of publishing_client and 400, Connect("publishing_client", 400), the MqttMgr's clientId and keepAlive attributes are updated with the values publishing_client and 400 consequently.

In order to create and send events the state automobile's deportment use the GEN() macro. For instance, the following statement sends a Receive event to the Collector object, which is referenced every bit a MqttMgr object's aspect by itsCollector pointer:

              GEN(me->itsCollector, Receive());

The get-go statement of the GEN() statement is the object that receives the upshot, whereas the second argument is the issue being sent, including event arguments (if there are whatsoever). The arguments must hold with the event parameters. For example, the post-obit statement generates a ConnRefused(code) event and sends information technology to the Collector object passing the code returned by the broker as an event parameter:

              GEN(me->itsCollector, ConRefused(code));

The thought of using params keyword to access the consumed event's parameters and GEN() macro to generate events from actions was adopted from Rational Rhapsody Programmer's code generator for purely illustrative purposes.

The state machine's default action in Figure 1 sets the callback that is called by MQTT-Reactive whenever a connection acceptance is received from the banker. This callback should be implemented within MqttMgr code. This callback must generate either ConnAccepted or ConnRefused(code) events for beingness sent to the Collector object as it shown below.

              static              void              connack_response_callback(enum              MQTTConnackReturnCode return_code) {                              /*...*/                            if              (return_code == MQTT_CONNACK_ACCEPTED)     {              GEN(me->itsCollector,              ConnAccepted());     }              else              {              GEN(me->itsCollector,              ConnRefused(return_code));     } }

The model in Figure i could be implemented in C or C++ by using either your favourite software tool or just your own state motorcar implementation. There are different tools available on the Internet to practise that, such as RKH framework, QP framework, Yakindu Statechart Tool, or Rational Rhapsody Programmer, among others. All of them support Statecharts and C/C++ languages. Moreover, some of them include a tool to draw a Statechart diagram and to generate code from it.

The state machine was executed from an active object called MqttMgr (MQTT Managing director), which provided strict encapsulation of the MQTT-Reactive code and it was the just entity allowed to phone call any MQTT-Reactive function or admission MQTT-Reactive data. The other concurrent entities in the arrangement as well as any ISRs were simply able to use MQTT-Reactive indirectly by exchanging events with MqttMgr. The usage of this mechanism to synchronize concurrent entities and to share data among them avoids dealing with the perils of traditional blocking mechanisms like semaphores, mutex, delays, or event-flags. Those mechanisms could cause unexpected malfunctions that are difficult and tedious to diagnose and fix.

The MqttMgr active object encapsulates its attributes as a gear up of data items. A data item designates a variable with a name and a type, where the type is actually a data type. A data item for MqttMgr object is mapped to a fellow member of the object'due south structure. The fellow member'southward name and type are the aforementioned as those of the object'due south data. For example, the customer aspect of the MqttMgr object blazon is embedded by value as a data member within the MqttMgr structure:

              struct              MqttMgr  {                              /*                ...                */                            struct              mqtt_client customer;                              /*                attribute client                */                            LocalRecvAll localRecv;                              /*                attribute localRecv                */                            };

The MqttMgr object'due south information are accessed and modified directly without using accessor or mutator operations. For case, customer and localRecv are accessed through the me pointer, which points to an instance of MqttMgr.

              mqtt_recvMsgError(&me->customer, &me->localRecv);

The MqttMgr has the list of attributes shown in following table.

Attribute	Type	Description
clientId	char [23]	Information technology identifies the client to the server. See MQTT v3.1.1 section iii.1.three.ane
keepAlive	uint16_t	Fourth dimension interval measured in seconds. See MQTT v3.ane.ane section three.i.two.x
topic	char [20]	It identifies the data aqueduct to which payload data is published. Meet MQTT v3.ane.1 section 3.3.2.i
qos	uint8_t	Level of assurance for delivery of this message . See MQTT v3.i.1 department three.three.2.1
client	struct mqtt_client	Instance of MQTT client
sendbuf	uint8_t [2048]	A buffer that volition be used for sending messages to the broker
recvbuf	uint8_t [1024]	A buffer that will exist used for receiving messages from the broker
operRes	enum MQTTErrors	An enumeration of error codes
errorStr	const char *	String which indicates the final error bulletin
localSend	LocalSendAll	Data context on sending letters
localRecv	LocalRecvAll	Data context on receiving letters