The Internet of Things (IoT) was born when Edge devices were interconnected via the internet allowing them to send and receive data back and forth. Edge devices are actually embedded systems processing data in real-time close to the physical environment in which they are deployed. Functional Size Measurement (FSM) is a tool to measure functionality provided by a software and obtain technical indicators early in the design phase. The COSMIC method is an international standard for functional size measurement of a software. A study [2] discussed FSM for Internet of things (IoT) real-time embedded software and proposed a guideline using Arduino. Another study in [8] proposed the idea of Universal IoT metrics and automated some metrics proposed. This paper presents an approach to automatically measure COSMIC functional size of any IoT Edge Device code. This paper is based on the measurement procedure rules presented in [2], and it attempts to complete the tool presented in [8].
The Internet of Things (IoT) is a collection of Edge Devices sending and receiving data via networks that needs to be processed and analysed.
Instead of sending IoT data systematically back to a datacenter or to the cloud, edge computing, a technique for computing on site where data is received or used, allows IoT data to be captured and processed at the edge.
IoT and edge computing work well together to quickly analyse data in real-time.
An IoT system typically operates by transmitting, receiving, and analysing data in a feedback loop perpetually. Humans or artificial intelligence and machine learning can perform analysis, either in near real-time or over a longer period of time.
When anything is described as smart, IoT is usually implied, e.g., autonomous vehicles, smart houses, smartwatches, virtual and augmented reality, and industrial IoT.
The COSMIC method is an International Standard: ISO/IEC 19761 Software Engineering –
COSMIC – A functional size measurement (FSM) method and as greatly contributed in improving
Software measurement and estimation processes in both research and industry [
In 2017, [
Many automated COSMIC FSM procedures have been proposed in the literature for other
diferent domains e.g., aeronautical [
This paper is based on the measurement procedure rules presented in [
This paper is organised as follow: Section 2 presents related works including overviews of [
This section discusses related work on Functional size measurement for IoT as well as papers investigating IoT metrics.
The study in [
First, data group movements and the associated data manipulations that determine software functionality according to COSMIC are: ENTRY (E) and EXIT(X) data movements that allow data exchange with users across a boundary. READ (R) and WRITE(W) data movements that allow data exchange with the persistent storage.
Second, functional processes which are defined according to COSMIC as a set of data movements, representing an elementary part of the functional user requirements (FUR) for the software being measured that is unique within these FUR and that can be defined independently of any other functional process in these FUR. A functional process may have only one triggering Entry. Each functional process starts processing on receipt of a data group moved by the triggering Entry data movement of the functional process. The set of all data movements of a functional process is the set that is needed to meet its FUR for all the possible responses to its triggering Entry.
The mapping of COSMIC elements to Arduino elements is made in [
Hence, each INPUT pin used as an argument in a function is considered as a COSMIC Entry.
Meanwhile,each OUTPUT pin used in as an argument in a function is a COSMIC Exit. Further
more, each function call used for reading data from EEPROM counts as a COSMIC Read.
Meanwhile, each function call used to write data to EEPROM counts as COSMIC Write.
The study in [
Lastly, the authors in [
This section presents the prototype tool implemented for automating COSMIC functional size
measurement for IoT Edge devices relying on the measurement procedure presented in [
The tool is divided into two modules as depicted in Figure 1. The first module retrieves the source code from the micro-controller. The Second module measures the FSM of the retrieved source code in Comic Functional Points (CFP). The Message Queueing Telemetry Transport (MQTT) protocol which is an extremely lightweight publish/subscribe messaging transport protocol is used in our tool for sending the retrieved code from the first to the second module as well as publishing the size in CFP of the retrieved code. Hence, each module of the tool acts as an MQTT client.
Initially, a connection between the micro-controller and a MQTT client should be established, this connection is aimed to send the code of the micro-controller via the internet to another MQTT client (Module 2 of our tool proposed) to measure automatically the COSMIC functional size of the retrieved code in CFP. HiveMQ MQTT cloud broker is used. 3.1. Module 1 The main objective of Module 1 is to retrieve the source code running on the micro-controller and to send it using MQTT. Since the programming languages used on Edge devices are not a high level language, the source code cannot be retrieved automatically (e.g., as opposed to JavaScript through invoking a .body() function call to retrieve the functions of the source code). Hence, in order to retrieve the source code of Edge devices (e.g., Arduino, ESP), 4 potential approaches are explored: • Approach 1: This approach requires manual manipulations from the user’s side. First, the user has to retrieve the .elf file from the Arduino Ide by ticking the compilation option in preferences submenu found in the file menu. Secondly the user has to use either AVR or Xtensa tool using specific commands to convert the .elf file to assembly and next the user has to install MQQT CLI and establish connection with a client using specific commands that can be scripted and copy and paste manually the assembly code in a message and send it via CLI. To that end, this approach was excluded due to the multiple manual steps that are needed by the user. • Approach 2: This approach consist of saving the code as a pre-requisite in the EEPROM and the FSM tool includes a function that automatically retrieves the code from EEPROM. This approach can be easily automated. However, it has its own drawbacks. For instance, the EEPROM has limited amount of storage size and hence codes with size exceeding a certain threshold will not fit in the EEPROM. In addition to the fact that the EEPROM might be used by the program itself to store and retrieve functional or calibration data needed by the Edge device. In addition, certain rules have to be followed by the user: the Edge device programmer should pass the starting address in the function to be called to read the source code from the EEPROM as well as the Lines of codes including the separators used. Secondly, the Edge device programmer must store after every line of code a special character, e.g., “!” , since the EEPROM is byte addressable and an indicator on where every line of code starts and where it ends is needed. Finally, the Edge device programmer has to store another special character, e.g., “@”, in the EEPROM to mark the end of the file. See example in Figure 2. • Approach 3: This approach consists of saving the code as a pre-requisite on an external SD- card and the FSM prototype tool proposed includes a function that automatically retrieves the code from the SD-card. Using an SD-card is as a practical solution when it comes to storage, however, it requires extra Hardware connections to the micro-controller of the Edge device. • Approach 4: This approach consists of storing the source code in the file system of the micro-controller, our tool includes a function which parameters should be passed by the user which is the source code and the function automatically saves it in the file system. Next, another function can be called without passing any parameters to retrieve the source code from the file system and send it via MQTT to the Module 2 of the tool. The code has to be passed as a String and line separators ”\n” have to be added to indicate the end of each line, as shown in Figure 3.
For instance, when using boards that do not support File systems such as Arduino, we recommend following Approach 2 in case of a small size code (in Bytes) or to use an external SD-card (Approach 3) if the source code exceeds a certain size in Bytes. Conversely, we recommend Approach 4 when using ESP boards since ESP boards support File systems which storage capacity is suficient for any code size without neither acquiring extra hardware connection to store the code in an external SD-card nor facing the limitations of memory storage capacity of the EEPROM.
Once the source code has been extracted, the connection between the MQTT client and MQTT broker is done and next the source code is published via the network to another MQTT client. To ensure the re-usability of our functions, they are wrapped in a class enabling them to be imported: this requires Wi-Fi credentials as well as the Hive MQTT credentials to initialize the class. In addition, functions relevant to the approach used should be called with the required parameters in the specific format, as described earlier, and the function will automatically publish the source code to a specific code to be received by the second MQTT client (Module 2 ) to measure the functional size in CFP of the source code retrieved. 3.2. Module 2 Module 2’s main functionality, implemented as a JavaScript MQTT client, is to automatically measure the COSMIC size of the source code retrieved. Module 2 (the second MQTT client) receives the source code from the first MQTT client (Module 1) as a String. This code is analyzed and the COSMIC Entry, Exit, Read and Write data movements are identified in the code. JavaScript is used because it is a high-level language that supports String comparison which is needed for the Data movement identification.
The libraries that are taken into consideration in the current implementation of the prototype tool proposed are: • Serial library: used for serial communication between the micro-controller and a serial monitor or another micro-controller. Hence, its function calls will either represent an Entry or an Exit. • EEPROM library: used from reading and writing data to and from persistent storage.
Hence it functions calls either represent a Read or a Write. • Liquid Crystal: used to control print data on an LCD (Actuator). Hence, its function calls are considered as an Exit. • WiFi : Enables connection with between edge devices and internet network . Hence, its function calls will either represent an Entry or an Exit.
The usage of our prototype tool is not restricted on a certain IoT domain since Module 2 of the tool relies on parsing the source code retrieved from the micro-controller and checking line by line for the existence of any data group movements. It is also worth mentioning that the function call responsible for source code retrieval and sending it via MQTT to the second module will not infer with other tasks running on the Micro-controller since the function is called once in the Set-up function and will not run perpetually so no need to endure extra costs or re-schedule the tasks running .Hence,the steps required to use our prototype tool are: 1. Register to HiveMQ cloud and create a cluster. Next, create 2 web Clients and save their credentials. 2. Use the credentials of the first web client in the second module of the tool to establish a connection with the MQTT broker and subscribing to the topics of interest: Lines of code, CFP, Entry, Exit, Read, Write. 3. Use the credentials of the second web client as well as wifi credentials in the IoT Edge device to establish a connection with the MQTT broker and calling the function dedicated for sending the code with the appropriate parameters previously mentioned relying on any of the 3 automatable approaches described earlier to the first web client to measure the COSMIC functional size in CFP. The details of the measurement results are displayed in the console. It is possible for the IoT Edge device to subscribe to the same topics as the JavaScript client if the measurement result is needed to be displayed on the IoT Edge device (e.g., displaying the COSMIC size of the Edge device’s code on its LCD). Hence, it is only required from the user to choose the most convenient approach required for source code retrieval in module 1 of the tool based on the parameters mentioned above which are the type of the board, the size of the source code running , possibility to add extra-hardware connections ,afterwards, the user has to merely call the function corresponding for the approach that was adopted provided that the prerequisites of the approach are already met and that the connection using the Wi-Fi credentials is established. The MQTT client of the second module has to be connected to the MQTT broker before attempting to send the source code via the first module since the second module receives the code published from the first module.
In order to verify the accuracy of the automated functional size measurement of Module 2, the
example code used in [
The automated measurement result of the example code produced by Module 2 of our prototype tool proposed is shown in Figure 4: the prototype tool has correctly and accurately identified 3 Entry and 14 Exit data movements for a total COSMIC functional size of 17 CFP.
The second test consists of establishing the connection between our JavaScript client and the IoT Edge Device and verifying that the Edge Device is able to send the source code properly to the JavaScript client. For this purpose, the JavaScript client subscribed to a new topic namely (test/topic) which is also used by the IoT Edge Device (the Arduino client in this example) to publish its source code. The code in Figure 6 is used to retrieve the source code from the EEPROM and publish it to the topic named (test/topic) to be received by the JavaScript client.
The connection was established successfully and the Arduino client was able to send its source code to the JavaScript client, a simple code example that prints the word “IoT” to the serial monitor is stored in the EEPROM (approach 2) and the Arduino client was able to retrieve the code from the EEPROM and send it to the JavaScript client. The simple code example used is shown in Figure 7. It is important to note that the code sent by the Arduino broker did not include the comments to save space, since we followed the second approach that requires as a prerequisite storing in advance the source code (without the comments) in the EEPROM. See Figure 8.
Finally, the code sent by the Arduino client is measured automatically by the JavaScript client and then the results are published as shown in Figure 9.
Once the functionality of the prototype tool proposed has been tested with simple code examples,
the source code from [
Testing the real life example code inferred the following key points about the tool accuracy and usability : • The prototype tool currently is able to identify multiple function calls included in the basic libraries used for communication (e.g., Serial, Wifi) as well as basic function calls used for interacting with functional users (i.e. sensors and actuators). Nevertheless, measuring functional size accurately requires detailed analysis of every function call found in every library which is a dificult task due to the big number of these libraries. • The current version of the prototype tool restricts the way of writing the Edge device code. To clarify, the tool assumes when defining a function that every (”{”) is written in the same line where the function name, conditional statements or loops are written. In addition, comments are assumed to be written in separate lines from the actual codes. Otherwise, the prototype tool will not be able to identify all COSMIC Data Movements successfully. For instance, in the real-life example temperature sensing code, the tool failed in identifying 3 data movements identifications: – 1X: Serial.print(”http://”); because // was considered a comment by the tool; – 1E: float reading = analogRead(LM35); and 1X:client.println(””); had comments in the same line. H
Hence, the main limitation lies in the numerous number of libraries supported by Arduino or ESP boards dedicated merely for certain functional users (i.e sensors or actuators). This causes the inability of our prototype proposed in identifying data group movements related to these libraries’ function calls. 1X:WiFiServer server(80); 1E:Trigger (setup function call) 1X:Serial.begin(115200); 1X:delay(10); 1X:Serial.println(); 1X:Serial.println(); 1X:Serial.print(”Connecting to ”); 1X:Serial.println(ssid); 1X:WiFi.begin(ssid,password); WL- 1E:while (WiFi.status() != WL
CONNECTED) 1X:delay(500); 1X:Serial.print(”.”); 1X:Serial.println(””); 1X:Serial.println(”WiFi connected”) 1X:server.begin(); 1X:Serial.println(”Server started”); 1X: Serial.print(”Use this URL to connect: ”) UNIDENTIFIED BY THE TOOL 1X:Serial.print(WiFi.localIP()); 1X:Serial.println(”/”); 1E: Trigger (setup complete) 1E: Trigger (setup complete) 1X,1E:WiFiClient client = 1X,1E:WiFiClient client = server.available(); server.available(); 1X:Serial.println(”new client”); 1X:Serial.println(”new client”); 1E:while(!client.available()) 1E:while(!client.available()) 1X:delay(1); 1X:delay(1); 1E:String request = client.read- 1E:String request = client.readStringUntil(’’̊); StringUntil(’’̊); 1X:Serial.println(request); 1X:Serial.println(request); 1E: lfoat reading = analo- UNIDENTIFIED BY THE TOOL gRead(LM35); 1X:client.println(”HTTP/1.1 200 1X:client.println(”HTTP/1.1 200 OK”); OK”); 1X:client.println(”Content-Type: 1X:client.println(”Content-Type: text/html”); text/html”); 1X:client.println(””); UNIDENTIFIED BY THE TOOL 1X: client.println(”<!DOCTYPE 1X: client.println(”<!DOCTYPE HTML>”); HTML>”); 1X: client.println(”<html>”); 1X: client.println(”<html>”); 1X:client.print(”Celcius tempera- 1X:client.print(”Celcius temperature =”); ture =”); 1X:client.print(temperatureC); 1X:client.print(temperatureC); 1X:client.println(”Farenheight tem- 1X:client.println(”Farenheight temperature =”); perature =”); 1X:client.print(temperatureF); 1X:client.print(temperatureF); 1X:client.println(”Updated”); 1X:client.println(”Updated”); 1X: client.print(”Not Updated”); 1X: client.print(”Not Updated”); 1X:client.println(”<br><br>”); 1X:client.println(”<br><br>”); 1X:client.println(”<a 1X:client.println(”<a href=/̈Tem=ON̈̈ ><button>Update href=/̈Tem=ON̈̈ ><button>Update Temperature</button></a><br Temperature</button></a><br />”); />”); 1X:client.println(”</html>”); 1X:client.println(”</html>”); 1X:delay(1); 1X:delay(1); 1X:Serial.println(”Client dison- 1X:Serial.println(”Client disonnected”); nected”); 1X:Serial.println(””); 1X:Serial.println(””);
The Internet of Things (IoT) is a collection of Edge devices interconnected via the internet. Edge devices process data in real-time close to the physical environment in which they are deployed. Functional Size Measurement is an omnipotent tool to measure functionality provided by a software and obtain technical indicators early in the design phase.
This paper presented a prototype tool to automate the COSMIC Functional size measurement
of IoT Edge devices. The measurement automation is based on the rules proposed in [
In the future, we intend to improve Module 2 by including more Arduino and ESP libraries to
the measurement rules to identify the Data movements concerned and measure their size in
CFP accordingly. In addition, a more user-friendly interface for our JavaScript client will be
proposed by integrating it to the tool proposed in [