A Gray Box-based Approach to Automatic Requirements Specification for a Robot Patrol System

The black box-based requirements specification models representative by the use case model focus on specifying system behaviors exposed outside. While these models are sufficiently effective in specifying requirements for business applications behavior, they are limited in specifying requirements for embedded systems with relatively very short interaction sequences with users. To solve this problem, we have proposed a gray box-based requirements specification method to specify the inner logic of an embedded system, including a tool for automatic generation of requirements specification from some analysis models in our previous work. This study proves the benefits of the proposed software requirements specification method by applying it to a robot patrol system and showing the possibility of general use of the proposed method in the embedded system domain. Compared with our previous work, we enhance the tool for automatic generation of requirements specification, called SpecGen, and prove the benefit of the proposed method from multiple aspects. The application result on the robot patrol system case is quantitatively demonstrating that our proposed requirements specification method improves development productivity and enhances overall software product quality, including code quality. Keywords—Embedded system; automatic requirement specifications generation; mobile robots; use case specification

I. INTRODUCTION
Embedded software refers to software embedded in various electronic products, from small appliances, including mobile phones, digital cameras, and MP3s to robotics systems [1]. Scenario-based specification techniques widely used in business applications are often used in the requirements specification for embedded software. The primary purpose of the scenario-based specification technique represented by the use case model [2] is to describe the interaction between the system and the environment in which the system is used. Business applications are realizing real-world business as services supported by software systems. Hence, most required behaviors of a business application can be captured from the statements for specifying interactions between the user and the system. Although the service provided by the embedded system results from each event generated by the user, it cannot be observable from the outside of the system which internal action the system performs until the service result is derived. In other words, requirements extractable from visible interactions between an embedded system and environmental factors in which it is used are relatively limited [3,4].
Thus, when the requirements for an embedded system are specified using a use-case model, the amount of information identified in the requirements specification is insufficient as a specification for developers [5]. As is shown in Fig. 1, for an example of a generic flow of events for "Power On" use case of an embedded system is specified as: (1) A user pushes the power-on button to start the system; (2) The system is invoked and waits for the user's other request. Such use case specification is insufficient to be used as a requirements specification to guide the development team designs the embedded system. To overcome this lack of information when the use-case model is applied to the embedded system requirements specification, most existing studies [6][7][8][9] prepopulate various design diagrams such as state, sequence, class, or data flow diagrams .etc.
Even if we select a suitable design diagram to specify the inner mechanism of exposed system behavior, we should decide the depth of each design diagram. The deeper the depth of the diagram, the more sophisticated the system's behavior can be included in the requirements specification. We usually face a "what versus how" dilemma [10] in specifying requirements, which means a "how" in the preceding step means again the "what" in a subsequent step. Over-elaborated design diagrams in the requirement stage could violate the definition of a requirement in that it specifies solutions, not problems [11]. Furthermore, it can cause a raising initial system development cost. The requirements model, which includes the requirements set for embedded software developers, should provide the interaction requirements between the system's internal components. As the developers could refine the interaction between components by digging the depth, guidelines for the appropriate elaboration depth are needed to obtain the necessary information in the requirements stage.
Our previous work [12] proposed an extended requirements specification model from use case specification to satisfy these needs. The use case specification guides us to maintain a view of the target system as a single black box [13] when we specify requirements. In contrast, we named the proposed model a "gray-box" based requirements specification in the sense that it is a model based on a perspective that partially looks at the interaction between top-level components among interactions inside the embedded system. It suggests the trade-off between the elaboration depth and the effort to design interactions among internal components of an embedded system when utilized as a requirements specification. www.ijacsa.thesai.org The work reported here extends our previous work [12] in the following aspect:  To show the extensibility of the proposed model through the application case of the more complex embedded system. While the scope of the case study was limited to a module of a mobile phone in [12], in this study, we extend the applicable domain area of the proposed model to the whole of a robot patrol system that is a different domain from the previous work. To prove the extensibility of the applicable area of the model is to prove that the proposed gray box-based requirements specification model can be a general method to specify requirements of embedded systems, not for only a specific system or domain.
 To prove the benefit of the proposed model using more various aspects. The author in [12] explains the benefit by showing that each elapsed time for the software development phases following the requirements phase is decreased when the proposed model is provided to the developers. Besides the enhancement of the productivity of developers, in this study, we show the software product quality and the code quality are also enhanced from using the proposed model through the more sophisticatedly designed experiment.
 To update the automatic generation of the gray boxbased requirements specifications, which is renamed SpecGen. We re-developed the tool for utilizing a more prevalently used and better supported UML authoring tool when developers make an analysis model that is the source of the gray box-based requirements specifications. This work could be valuable in helping more developers use the proposed model and the supporting tool.
The rest of the paper is organized as follows: Section 2 investigates the trend of existing studies. Section 3 gives an overview of the gray box-based requirements specification method. Section 4 explains an automatic transition from a design diagram in UML to Microsoft Word typed tabular specifications implemented in SpecGen. Section 5 shows each step of requirements specification for a robot patrol system and some fragments of the state diagram and automatically generated specifications by SpecGen. Section 6 explains how we designed an experiment for showing the effectiveness using the proposed requirements specification model for the robot patrol system and discusses the results of the accomplished experiment. The conclusion of the paper is discussed in Section 7.

A. Model-driven Development based Approaches
In embedded software development, model-driven development (MDD) based approaches are now widely used. MDD has the merit that developers can find the software's www.ijacsa.thesai.org essential features, thanks to information on the complicated system structure as an abstracted model [14]. The most typical MDD methods are the COMET method by H. Gamaa [15], which integrates object-oriented and concurrent processing concepts. The OCTOPUS method [16] models the system using a structural, functional, and dynamic model.
The research that addresses the requirements specification problems based on the model created by applying an MDD based approach can be found in [17][18][19]. Lattemann and Lehmann [17] define controller, actuator, and sensor as three main components that comprise the embedded system and suggest that the controller that controls the entire system should be intensively specified among the three roles. Lavi and Kudish [18] classify the model to be analyzed into the Elevel representing the external structure and behavior of the system and the S-level representing the conceptual model of the system inside. They suggest an automatic documentation method for requirements specifications based on activity diagrams and state diagrams for specification and analysis of E-Level processes. Glinz [19] utilizes hierarchical activity diagrams after the relation between system state and objects that comprise the system with a source for the specification of requirements in an embedded system is identified.
Existing works only refer to the necessity that the entire system should be divided into lower systems. Each modeling phase should be recursively applied for the requirement specification of the embedded system. But there is no guideline for stopping the recursion for the elaboration depth of the model to be built. To solve this problem, we have started this study from the work that defines the elaboration depth of the analysis model for requirements specification, which was ignored in the previous studies while preserving their advantages.

B. Requirements Pattern-based Approaches
Another notable approach for requirements specification for embedded systems is requirements pattern-based one. Denger et al. [20] propose a natural language pattern to specify requirements in the embedded systems, including 1) meta models for the description of requirements and 2) metamodels for events and responses that we use to verify the completeness of the pattern language. The proposed patterns seem slightly less common compared to commercial phrase requirements. Matsuo et al. [21] use natural language controlled for requirements, limiting how they can combine simple sentences into more complex sentences. They proposed three different types of frames: noun frame, case frame, and feature frame, and they use the frames to parse requirement specifications, and organize them according to different perspectives, and verify requirement completeness. However, there exists a limit that the frame-based approaches seem to be more difficult for non-specialists to understand and apply. Konrad and Cheng [22] define formal specification pattern systems for embedded systems. These patterns are used to describe system properties mapped to linear time logic. Patterns are classified into qualitative (occurrence or order) and real-time (period, periodic, or real-time) patterns. There is a limit that we should specify the supporting model in a UML 12 variant. Postet al. [23] provide the successful application case of this system to automotive requirements. However, the application coverage is not complete.
A pattern is a set of solutions that are commonly applicable to recurring problems. Therefore, the pattern-based approach has an inherent limitation in the scope of its application. This study is different from the pattern-based approach in that it aims to develop a specification method generally applicable to the embedded systems.

III. OVERVIEW OF GRAY BOX-BASED SOFTWARE REQUIREMENTS SPECIFICATION MODEL
The proposed gray box-based software requirements specification for embedded systems leverages partially cultivated analysis artifacts. However, designing all aspects of an embedded system is not proper in the requirements specification phase, considering that software requirements should focus on what services should be provided in the future. Thus, we have limited the design area to the following two diagrams to which the collaboration behavior between the inner components is to be extracted:

A. Top-level State Diagram of a Controller
A state diagram that shows state changes in the system corresponding to events occurring inside and outside the system is a typical diagram used to design dynamic views of the embedded system. Therefore, we selected it as the diagram to specify the internal behavior of the system corresponding to the event specified in the use case specification. After choosing to use state diagrams as the source of the requirements specification, another remaining issue was identifying which component could represent the state transition of a whole embedded system. A state of an entire system is a specific situation where specific values are assigned to all attributes of components comprising the system. Therefore, the question, which component should have the ownership of the state of a whole system is a controversial issue. Referencing Broy and Stauner [24], we have classified the roles of the main components in an embedded system into controller, actuator, or sensor. Among the three stereotypes of components, we defined the controller coordinating behaviors of other actuators and sensors as the component possessing the states of a whole system.

B. Sequence Diagrams Specifying Interactions of all Top Leveled Components -Controllers, Sensors, and Actuators
The proposed model specifies events exchanged among external subjects in a time sequence. As a flow of events in a use case is reflected in a sequence diagram, each internal interaction invoked by external stimuli from an actor is also designed using a sequence diagram to keep the same context. The owners of the events on the sequence diagram created in this step are actors, controllers, and sensors/actuators (that execute the controller's commands). The states in the topleveled state diagram of the controller are added as annotations on the lifeline of the controller object in the sequence diagram, as depicted in Fig. 2. In the next step, the sequence diagram added state transitions of a whole embedded system is the source of the automatically generated requirements specification. www.ijacsa.thesai.org  As shown in Fig. 3, once the two kinds of design diagrams are completed by developers, the following three different software requirements specifications can be automatically generated.
 External Interaction Scenario Specification: specifies the interaction between a system and an actor corresponding to the system's external environment. The information included in this specification is equivalent to the information contained in the use case diagram.
 Component Collaboration Specification: specifies the state changes of a controller due to inter-component interaction. The information included in this specification contains state-related information included in the state diagram for the component of the controller that controls the actuator and sensor of the embedded system. In addition, the information recorded in the sequence diagram, which is the result of designing the sequence of commands that the controller receives external stimuli and sends commands to other actuators and sensors, is extracted as this specification.  Our proposed method does not exclude the steps of the existing black-box requirement specification but includes them. Fig. 4 illustrates each step to construct those specifications. A context diagram and a use case model are specified due to steps 1~3 in Fig. 4. A context diagram represented by UML (Unified Modeling Language) shows which users or interfacing systems are engaged to provide a service in the target system. Specifying the context diagram is not included in the general guidelines of the use case model. However, embedded systems are literally "embedded" in a hardware system. Thus, clear identification of external objects that an embedded system should interface with is critical. We also marked interface systems outside as actors in the context diagram for consistency with the use case model. A use case diagram that specifies the system's services is the same as a typical use case diagram. Steps 4~5 are for developing a design artifact, including a top-level state diagram of a controller and sequence diagrams for specifying collaboration between the controller and other sensors/actuators to respond to each stimulus outside of an embedded system. The following steps 6~8 are to automatically extract the three specifications explained above from the designed diagrams through steps 4~5. We also developed an automatic tool, SpecGen, to support these steps. The requirements specifications generated by SpecGen define the internal behaviors of an embedded system, which will be utilized as a guideline set for embedded system developers in the following development phases.

IV. SPECGEN: A TOOL FOR AUTOMATIC GENERATION OF REQUIREMENTS SPECIFICATION FROM DESIGN DIAGRAMS
One of the originalities of our work is to provide a tool for top-leveled design artifacts to be transformed to requirements specifications automatically. This feature is important from three perspectives:  In writing the requirements specification as a development guideline for developers, the information included in the design diagram created by the developer or designer is linked without loss.
 Since most developers refer to automatically generated requirements specifications and development proceeds, as a result, it does not matter if very few members with design ability use various UML diagrams in the development team.
 And, the support of automated tools can minimize the effort required to write requirements specifications in hand.
Our previous study [12] utilized ArgoUML [25] as the authoring tool for designing diagrams. In this study, we changed the authoring tool to StarUML 4.0 [26] as ArgoUML has not been versioned up. Fig. 5 shows a fragment of the transformation from a UML diagram in StarUML to a requirements specification as a Microsoft Word file by SpecGen. For using SpecGen, the first step is to extract diagrams authored using StarUML to an XMI file. To extract needed information from the XMI file, we should understand the structure of each object in the XMI file representing the UML model extracted from StarUML. Although we can catch the owner object of the first lifeline is "User" intuitively from the given sequence diagram, we can find it out after tracing several lines in the exported XMIs, as depicted in Fig. 5. It depicts the example with the shortest trace selected due to space constraints, but in some cases, the desired information is extracted through a traverse of more than ten lines of XML. Similarly, we analyzed all relevant XMI structures and compared the attributes in each requirements specification we defined. We implemented the transformation rules identified as such with SpecGen. www.ijacsa.thesai.org We selected a robot patrol system (RPS) as a target system to which the proposed requirement specification method is applied. RPS is a robot system that provides a service by sending out an alarm when an intruder is detected as it patrols the designated section. The reason to choose a robot system as a target system is that it is one of the typical system domains requiring the three components -controller, sensor, and actuator -in an embedded system as defined by Broy and Stauner [24]. Whereas an operation given for a robot patrol system is simple as "Keep patrolling here," many inner-sided interactions invisible to users are required to patrol within an area. These features are consistent with the feature of the target domain area to which we apply the proposed method.
The followings are the results and explanations of each step in Fig. 4 of the proposed model applied to RPS.
Step1: Identify the external interface of a system Step2: Identify functional requirements of the system Fig. 6(b) is the use case diagram, which specifies functional services be provided by the target system. The use cases of RPS are: Patrol, Drive to a point, Notify location data, Register the obstacle location, Set configuration. And, the active actors that invoke a use case are the data source of the context diagram. So, the active actors of RPS are User, SonarSensor, and Encoder. The data sources of the context diagram come to be passive actors being the systems to be interfaced in the use case diagram. In RPS, Speaker and WheelActuator are the passive actors.
Step 3: Specify use case descriptions Table I shows the use case description of the "Patrol" service. We select a tabular style, and most compartments of the use case specification are specified, including preconditions and post-conditions. There are one basic flow and two alternative flows in the "Patrol" use case. www.ijacsa.thesai.org

Use Case Name Patrol
Actor User

Brief Description
The robot patrols the area based on the range of user input.

Basic Flow of Events
This use case begins when the user enters the destination range for patrol by GUI and gives the order to start.
[1] The robot patrolling system(RPS) saves the start and destination positions and switches direction to destination positions. And the RPS gives the start command to Wheel Actuator. [2] The RPS reads the sensor values and identifies the intruder. If the intruder is detected, the flow goes to [A1]. [3] The RPS reads the current location and checks whether the RPS arrives at the destination.
[3.1] If the robot arrives at the destination, give the stop command to Wheel Actuator, where the use case ends. [3.2] If the robot does not arrive at the destination, the flow goes to [2].

Alternative Flow 1
[A1] Intruder detection [1] If the intruder is detected, the RPS gives a stop command to the Wheel Actuator.
[2] The RPS causes alarm bells through the speaker, at which point the use case ends.

Alternative Flow 2 [A2] User's stop command
If the user gives the order to stop at any time, the RPS gives a stop command to the Wheel Actuator, at which point the use case ends.

Pre-conditions
The RPS was initialized state. The robot's starting position is (0, 0). And the direction of the robot is assumed to be 90 degrees.

Post-conditions
The RPS is the stationary state according to user instructions.
With the artifacts depicted in Fig. 6 and 7, we can see what should be developed for the RPS. However, it does not provide sufficient information to guide what should be implemented because it defines only the interactions between actors and the system. If only these artifacts are given to developers, comparatively many decisions should be made by individual developer's capability to realize the specified requirements. If only these artifacts are provided to the developer, the individual developers must make a relatively large number of decisions, which could be a significant burden. The burden to the developers comes from the lack of details in requirements specification will be discussed in Section 6 with experimental results.
Step 4: Analyze the state transitions of the controller In an embedded system, various sensors and actuators are equipped. However, only the controller has a meaningful state in an embedded system during the system's execution as other sensors or actuators are passive objects that receive commanders from the controller. For this reason, the state diagram of a controller should be created as a diagram explaining the behaviors of a whole embedded system. Fig. 7 shows the top-level state diagram of PatrolSystemController, which controls all other components in RPS. There are five meaningful states while the PatrolSystemController runs: Idle, Initialized, Patrolling, StoppedAtTheDestination, StoppedByIntrution.
Step 5: Identify collaboration between inter-components After analyzing the state transitions of the controller, the next step is to identify collaboration between components. According to the use case specification in Table I, there are a basic flow and two alternative flows in the "Patrol" use case. Fig. 8 is the sequence diagram for the scenario combining the basic flow and alternative 2 (intruder detection). The one different point comparing with typical sequence diagrams is that the states are additionally annotated on the lifeline of the www.ijacsa.thesai.org controller. We can confirm that the four states-Idle, Initialized, Patrolling, StoppedByIntrutionwhich are related to the scenario, are annotated on the lifeline of the PatrollSystemController in Fig. 8. The collaboration in Fig. 9 shows that PatrollSystemController controls the sequence of messages to WheelActuatorIF, SonarSensorIF, and SpeakerIF, identified as actors as external modules to interface in the use case diagram. DirectionCalculator and IntrusionDetectionIF newly identified in designing the sequence diagram are also identified as the objects collaborating to provide the "Patrol" service.  (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 12, No. 9, 2021 638 | P a g e www.ijacsa.thesai.org Unlike the general sequence diagram, one more thing to note is that the operation connected to each message in the sequencediagram must match the operation in the state diagram designed earlier. The operations that appeared in the state diagram and the state diagram are identical. As a result, the sum of the sequence diagrams created as many times as necessary contains all the information identified in the state diagram. Thus, the source of automatic generation of specifications through the following steps is the set of sequence diagrams as the result of step 5.
When step 5 is completed, sequence diagrams are created for each scenario combined based on the flow of events of the use case. As described above, the sequence diagram guided by the proposed model additionally specifies the controller's state transition information in the timeline. Using SpecGen, three additional requirement specifications are created through steps 6-8 based on the controller's state transition and the message sequence information that the controller controls to perform the scenario.
Step 6: Specify external interaction information First, the contents of the external interaction scenario specification described in Fig. 9(c) are the same as the previous use case specification information. The external interaction scenario specification table specifies the stimuli and reactions between external actors and the whole system. Fig. 10 shows the relationship between the diagram and the automatically extracted and generated fragment of each specification. For understanding, the matching information is denoted by the same black-boxed number. The generated row in Fig. 9(c) specifies that User invokes startPatrol (External Stumilus) when the system is idle (Current State). Then, UserIF, PatrolSystemController, DirectionCalculator, WheelActuator-IF, SonarSensotIF, IntrusionDetectionIF, SpeakerIF (Owner Component) collaborate each other. The system's last reaction is to alarm (System Reaction), and the final state is stopped by intrusion.
The specified content covers just a part of the "Patrol" use case. Fig. 9(c) specifies the external interaction scenario specification, including another scenario for the regular patrolling without any intrusion.
Step 7: Specify inter-component collaboration information The second specification is generated from the message passing information in the sequence diagram. As annotated in the sequence diagram, the state transitions of the controller are also reflected in the inter-component collaboration specification. It is extracted one-to-one from each message on a sequence diagram. The first action to invoke each collaboration starts at the message from GUI (Graphical User Interface) object to the controller, not the message from an actor already specified in the external interaction scenario specification. www.ijacsa.thesai.org  Fig. 9(d) shows the inter-component collaboration specification for the "detect intrusion while patrolling" sequence diagram. A user invokes the startPatrol event. And then, the event makes UserIF trigger startPatrol message when the controller's state is Idle. Fig. 9(d) captures the message passing after the triggering according to the information in Fig. 9(b). The state transition of the PatrolSystemController in executing the "detect intrusion while patrolling" scenario is depicted in the Transformed State column in the specification. The state is transit from the Idle state to the states of Initialized  Patrolling  Stopped by Intrusion in the sequence. Fig. 9(d) is the inter-component collaboration specification for the "Patrol" use case that includes the messages extracted from another sequence diagram for the regular patrolling scenario, denoted by shading. The content of Fig. 9(d) could be the key development specification for the developer in charge of the "Patrol" use case.
Step 8: Specify development requirements for unit components The third specification automatically generated by SpecGen is the unit component specification. SpecGen classifies each message captured in the inter-component collaboration specification according to the destination component. For example, Fig. 9(e) is a table of the group of messages -turnDirection, startWheel, stopWheel-of which destination component is the same, WheelActuatorIF. The table becomes the unit component specification of WheelActuatorIF later if all of the other incoming messages to WheelActuatorIF appeared in other sequence diagrams are added. Fig. 9(e) is the completely generated unit component specification for the WheelActuatorIF of RPS. In the case of WheelActuatorIF, the extracted actions to implement the scenario in Fig.10 are equivalent to the whole set of actions in RPS. The three actions required to implement WheelActuatorIF are the same as the APIs for WheelActuator, which means that the developer in charge of the WheelActuator should implement each action in the unit component specification. And the other developers can reference the specification when they need to call any actions of WheelActuator.

A. Experimental Design
To evaluate the effectiveness of the proposed requirements specification method, we designed an experiment. The scope of the experimental development is a basic flow and an alternative flow of the "Patrol" use case, which is described in www.ijacsa.thesai.org Table I. The participants of this experiment were 48 third or fourth-year university students from a computer engineering program, and they took the 8-week UML education course before they participated in the experiment. So, they can be classified as novice-level developers with more or fewer experiences in software development. 4 to 5 of them created a team.
Consequently, ten teams participated in this experiment. We divided the ten teams into two subgroups, one of which (group1) was given only the existing use case specification we named as the black box-based specification. The other group (group2) was given the artifact set of the provided requirements specification method as the gray box-based specification. The followings are the lists of the provided requirements specification artifacts for the two groups: The results we wanted to confirm through this experiment and the corresponding measures we used were as follows:  Enhancement of software development productivity: We compared the development time by asking each team to record each development phase's required time on the PSP sheet (Personal Software Process) [27]. The objective of the comparison is to confirm that the automatically generated requirements specifications from SpecGen contribute to decreasing embedded software development time.
 Enhancement of software product quality: We have defined 12 test cases for the given "Patrol" use case and tested the result from ten teams according to the test cases. And then, we compared the number of passed test cases related to functional aspects by each group, groups 1 and 2. We wanted to check if the provided requirements specifications from SpecGen can help the number of passed test cases increase.
 Enhancement of code quality: We expected that the requirements specifications generated from SpecGen contribute to enhancing the implemented code quality. If our expectation is correct, the number of bad symptoms from group 2 will be less than group 1. To confirm the assumption, we used the static analysis tool, Understand [28], to measure the number of bad symptoms inherent in the implementation codes from the two groups.

B. Experimental Results
 Enhancement of software development productivity: According to the PSP record documented during the two-week experimental development, the elapsed time of group1 in each development phase was shorter than group2. The teams' average total elapsed development time in group1 and group2 to develop the same use case, "Patrol," were 6,022 minutes and 3,950 minutes, respectively. The development time of group1 is the same as 66% of the elapsed time of group2.
As shown in Fig. 10(a), it is confirmed that group2 performed all steps, which are successive to the requirements specification, in less time than group1. In particular, the time taken for group2 to perform the design activity was less by 61% compared to group1. This decrease in development time can be interpreted as the benefit of the additionally provided requirements specifications generated by SpecGen, which include the analysis model in the early stage.
On the other hand, in the test phase, the execution time of group2 was less by only 8% compared to group1. In this experiment, the teams accomplished only integration tests since only a use case, "Patrol," was the development scope.
Since the use case specification is the exact requirements artifact provided for both groups, there is little difference in the information used for testing, so we can understand that there is no significant difference in the time taken for testing. To compare the time required for maintenance, we made the same request to change the requirements for each team belonging to both groups. The time to reflect the change request to the implementation code and test the changed code was measured as the maintenance time. As the teams in group2 can utilize the component collaboration specification generated from SpecGen, they took almost half the time of group1.
To ascertain that the elapsed time declines do not come from individual student's programming capabilities, we performed a simple regression analysis to analyze the correlation between the development time of each group and individual grades in programming-related courses. As a result, the R-Square value is 0.01, which explains no influence between students' development time and individual capabilities. Thus, the development time decline could be interpreted as the benefit of the proposed software requirements specifications.
 Enhancement of software product quality: We checked the number of passed test cases without any detected errors. The counted test cases are related to the functional requirements of the RPS, and the total test cases were 12. Fig. 10 Fig. 10(c). These errors can be risks in software maintenance or reduce the efficiency of memory utilization in the future. Moreover, there is a wide variation in the number of detected errors extracted from five individual teams in group1, from 5 to 130. These figures produce evidence that there was no design guideline for developers (students), which can cause the quality of source code to depend wholly on individual developers' capability. On the other hand, we found a comparatively slight variation, from 13 to 42, in the numbers of detected total errors from five teams in group2. It shows that the proposed requirements specifications helped developers in group2 to construct uniformly qualified codes.

C. Comparison with Related Work
As proved by the experimental result, the proposed method help enhance the productivity of embedded software development and the quality of the product itself and implementation code. We analyze that the enhancement comes from providing (1) guidelines for the degree of detail for each analysis diagram, (2) support of an automating tool for the creation of specifications from the analysis diagrams, and (3) the specification methods for each development phase. Table II shows the results of comparing several related works and this study, based on the satisfaction of the features as mentioned above. Compared with that other related work [13,18,29,30] limits providing guidelines for the degree of detail for each diagram and supporting an automatic tool for the proposed specification methods, Table II shows that this study acquires originality by providing the critical features mentioned above.

VII. CONCLUSION
This study presents a gray box-based software requirements specification method for embedded system domain and guidelines for constructing an analysis model in the requirements phase, which can be a source of requirements extraction. The case study on a robot patrol system development demonstrates how the proposed guidelines are realized during the analysis model development and which information is documented as a requirements specification from the analysis model. An experiment to show the quantitative benefits of applying the proposed specification method and the revised supporting tool is conducted. The result of comparing this study and several related works based on the critical success features that brought about the enhancement demonstrated by the experimental results is also discussed.
Compared with our previous study, the originalities in this work could be captured in that:  It proves the extensibility of the proposed gray boxbased approach to automatic requirements specification by showing the result from applying it to the whole system of a robot patrol system different from the case study in the previous work. It shows that the proposed model is not a solution dedicated to a specific domain.
 It shows the evaluation results of the proposed approach with more various aspects. In addition to the decrease of the elapsed time for the software development phases after requirements, this study shows that the number of passed test cases of the target system can be increased by using the requirements specification automatically generated by the SpecGen, an automating tool for supporting the proposed model. Furthermore, the evaluation result shows that the source code's detected bad symptoms are decreased by a meaningful amount in the development group using the proposed approach compared with the other group not using it. All of the findings were measured quantitatively on an actual robot patrol system development, not a contrived system only for an experiment, which can be one of the originalities of our work.
 It provides more accessibility for embedded software developers by utilizing a more popular open-source UML authoring tool. In the previous work, the automating tool runs with ArgoUML. But, ArgoUML is not a widely used tool, and the upgrading is stopped. In this work, we re-build the automating tool, SpecGen, integrating with StarUML, one of the most popular UML authoring tools. Thus, more developers who already experienced StarUML can easily adopt SpecGen in their development.


SDN-Enabled Hybrid DL-Driven Framework for the Detection of Emerging Cyber Threats in IoT

The Internet of Things (IoT) has proven to be a billion-dollar industry. Despite offering numerous benefits, the prevalent nature of IoT makes it vulnerable and a possible target for the development of cyber-attacks. The diversity of the IoT, on the one hand, leads to the benefits of the integration of devices into a smart ecosystem, but the heterogeneous nature of the IoT makes it difficult to come up with a single security solution. However, the centralized intelligence and programmability of software-defined networks (SDNs) have made it possible to compose a single and effective security solution to cope with cyber threats and attacks. We present an SDN-enabled architecture leveraging hybrid deep learning detection algorithms for the efficient detection of cyber threats and attacks while considering the resource-constrained IoT devices so that no burden is placed on them. We use a state-of-the-art dataset, CICDDoS 2019, to train our algorithm. The results evaluated by this algorithm achieve high accuracy with a minimal false positive rate (FPR) and testing time. We also perform 10-fold cross-validation, proving our results to be unbiased, and compare our results with current benchmark algorithms.

Introduction
With the growth of the Internet and the interconnectedness between each networking device, there is a dire need for security. The evolving Internet of Things (IoT) is raising various security concerns. The Internet of Things is described as a global network of interconnected devices that are assigned unique addresses. IoT devices use sensing features and different communication protocols. They have the computational capabilities to provide services and the capacity to analyze data. Some common IoT devices include cameras, video recorders, fire sensors, doorbells, electric switches and nearly all real-time sensing devices. The Internet of Things is an ever-changing technological world. It is a paradigm that links millions of smart devices, leading to the creation of a smart environment, such as smart health systems, smart cities, smart factories, intelligent vehicular networks and smart ecosystems [1]. This means that the lack of security can pose a serious risk to the devices and the entire system. The Internet of Things comprises heterogeneous networks and networking devices that use a variety of different protocols. The dynamic characteristics of IoT devices pose various concerns in the form of cybersecurity exploits such as denial of service (DoS) attacks, distributed denial of service (DDoS) attacks and various other kinds of malware [2][3][4]. Cybersecurity analysts continuously monitor networks for threat identification and repair every vulnerability; however, an attacker must only search for a single vulnerability to exploit the system. About 60% of experts spend an hour or two per day handling the network's security and operation; however, 80% of experts deal with at least one security incident in a single day [5]. With the advancement in computing and hardware technologies in recent years, cyber-physical systems have also shown rapid development. However, with the improvement and development in such areas, the variety of cyber-attacks has also grown rapidly; e.g., DoS attacks, which make the resources of the system unavailable. Replay attacks and deception attacks have also been discussed. The attack detection approaches and security controls are reviewed on the industrial level in [6]. Different types of protocol-following devices have diverse kinds of security measures that need to be followed. An integrated approach has not yet been invented to secure the complete IoT infrastructure. The traditional intrusion detection schemes are deployed, working at the infrastructure level, with firewalls or with intrusion detection and prevention systems to protect devices from attacks. However, these security measures are not sufficient when it comes to the seamless nature of IoT devices.
Software-defined network (SDN)-enabled infrastructure not only enhances the abilities of the underlying heterogeneous and dynamic environment of the Internet of Things but also provides the potential to configure and simplify network management. Thus, SDN serves as a paradigm that leverages resource-constrained devices without exhaustion as well as providing a platform to implement a security solution that does not overburden the underlying resource-constrained devices and provides an efficient and effective detection. A network's security system consists of various features such as firewalls, antivirus software and intrusion detection systems (IDSs). An IDS identifies and generates alerts about unauthorized system behavior such as use, replication, alteration and destruction. Integrating an IDS in an SDN is one of the best approaches for the surveillance of softwaredefined networks [7]. With the advent and viability of Artificial Intelligence procedures and the programmable features of the SDN, AI-based security solutions can be integrated into SDNs for improved security levels. There have been many AI-based techniques that have been utilized as network traffic classifiers; some of these techniques include Decision Trees, support vector machine (SVM), artificial neural networks (ANNs), Naive Bayesian, fuzzy logic, Genetic Algorithms, and K-Nearest Neighbor, which have shown ideal results with certain levels of accuracies. The need to present a flexible and robust framework has motivated us to develop a hybrid deep learning-based threat detection solution.
We developed an SDN-enabled Deep learning (DL)-driven solution for the detection of threats in the Internet of Things (IoT) environment that is cost-effective and highly scalable, as shown in Figure 1. We used a hybrid technique comprising the Cuda-Deep Neural Network Long short-term memory (CuDNNLSTM) and Cuda-Deep Neural Network Gated Recurrent Unit (CuDNNGRU) algorithms for efficient threat detection. We also implemented two algorithms for the comparison of our results: Cuda-Deep Neural Network Gated Recurrent Unit (CuDNN-GRU) and Cuda-Bidirectional Long short-term memory (CuBLSTM). Upon comparison, we found our algorithm to perform both efficiently and accurately. We used standard evaluation metrics for the evaluation of our results. The detection techniques use algorithms that are Cuda-enabled (the details of which are provided in Section 2). We used the CICDDoS2019 dataset, which is publicly available. The dataset consists of 14 different attack types, including DDoS attacks, reflection attacks, exploitation attacks and their subtypes. Details of the dataset are presented in the upcoming sections. Our proposed algorithms provide a multiclass detection approach, which to our knowledge is a novel contribution that was previously not available in the literature. We have also implemented 10-fold cross-validation, proving our results to be unbiased.
We organize the structure of our paper as follows. Section 2 consists of the background details as well as relevant work. In Section 3, the proposed architecture is given in full detail, whereas Section 4 comprises the experimental setup. We discuss the detailed results in Section 5. Section 6 of this paper presents conclusions.

Internet of Things
The Internet of Things is defined as an environment in which physical devices are integrated into the network in such a way that these objects become active participants of a business process. These objects can vary from network devices to sensors to household and health care items. These objects or devices are assigned a unique address and are together connected to the Internet. IoT contains a heterogeneous range of devices which can be wired or wireless using various kinds of protocols and can belong to different environments and networks [8]. According to recent Juniper research, it is estimated that more than 46 billion IoT devices will be in use by 2021. This consists of sensors and actuators as well as devices, demonstrating an increase of 200% compared to 2016 [9]. In any evolving paradigm of computing and networking, IoT is becoming an important component. The IoT revolution is growing enormously, resulting in immense growth in terms of monetary advantages and automation. The heterogeneous nature of IoT devices and the IoT environment brings with it a large number of challenges. These objects are designed to meet the requirements of specific user purposes, so it is difficult to come up with a common solution for all of them. As security is a prime concern in this era, achieving security for IoT devices is not simple. The diversities of these objects cannot be fit into a single protocol. Concerning the security challenges faced in the IoT environment, some real-time cybersecurity threats that are scanned for by antivirus software are specified. Symantec verified the presence of one of the first pieces of malware in IoT, Linux and Darlloz. Scanning the IoT devices in real-time for threat detection may result in a very unaffordable overhead.
Here, we introduce software-defined networks (SDN), the aim of which is to focus on network programmability. The control plane is separated from the data plane, giving the data plane merely the job of data forwarding. The control plane is in charge of all the decision-making for the entire network. By coming up with an SDN-based approach, we obtain a solution that can be applied to heterogeneous IoT devices. Therefore, in terms of its feasible real-world implementations, SDN guarantees a promising future for IoTs.

Software-Defined Network Architecture
Software-defined networking appears to be the most promising future networking framework. SDN consists of three layers: application, control and the data plane and corresponding north and south-bound APIs. The advent of the SDN paradigm has broken network management down to vendor-independent architecture through network programmability [10]. The separation of the control plane and data plane has led to the emergence of SDNs as a new networking paradigm. The novel and promising framework of SDN has shifted the entire control logic to a centralized control plane. Thus, the power and capability of SDNs lie in their centralized controlled architecture and intelligence. An SDN controller gathers insights (statistics) from the network elements by using the south-bound protocol. The south-bound protocol is the most important protocol of the SDN architecture and is responsible for the exchange of information between the controller and the networking devices [11]. One of the most important south-bound protocols is OpenFlow, which is a standard communication interface created by the Open Networking Foundation (ONF) and is characterized by the data and control planes of an SDN framework. This interface permits direct access to and manipulation of the forwarding plane of network devices such as routers and switches, thus enabling direct access as well as the control of the devices of the forwarding plane [12]. The SDN controller communicates with the switch through the south-bound API, where OpenFlow is the most used standard. Some other proposals are NOS, RYU and P4. There are multiple open software available for the NOS platform; i.e., Floodlight, POX, etc. SDN applications have the ability to program the network by using the north-bound API of the NOS [13]. OpenFlow comprises flow tables and activities that advise the switch how to process these flows and channels; as a result, the switch becomes associated with the controller, and in turn, the OpenFlow protocol is utilized by enabling the packets to be transmitted between a switch and the controller. A controller can view the entire network and govern all policies and decisions [14]. There are some appropriate concerns about the scalability of SDN; however, the limitations of scalability are not restricted to SDN only. The same challenges are also faced by the traditional control protocol design. Thus, we need to worry about the scalability issues in traditional networks instead of worrying about SDN. To preserve the scalability of SDN, control applications should be designed with the weakest level of consistency. In a typical data center, the switching elements can grow rapidly. This high amount of change in the control events generated in the network is enough to overload the centralized controller. One of the ways to avoid this problem is to install rules on the switches that result in the elimination of the control requests before they enter the control plane [15]. SDN faces a severe burden regarding the huge amount of control channel traffic because this may result in the increased delay of control messages. The programmable network virtualization based on SDN plays an important role in accommodating diverse services in cloud infrastructure [16]. The dynamic provisioning of virtual security functions enhances the scalability in the edge of networks to deal with the huge amount of traffic in the IoT. However, SDN plays a vital role in the dynamic reconfiguration of the network and provides new rules of networking on demand. The SDN has been proven to be a powerful and flexible enabler for network solutions. It plays a vital role in enhancing control decisions; in addition, SDN-based solutions provide scalability, dynamism, flexibility and centralized management [17]. The control plane of SDN is entirely programmable and can thus modify numerous functionalities. It can extend many networks on its data plane; e.g., edge, fog, vehicular networks and the Internet of Things [18][19][20].

Related Work
Deep learning has shown tremendous results in many fields of computer science. In [7], a network intrusion detection model is proposed that uses CNN. The raw data traffic is converted into image data format in real-time. By converting data to image format, the number of computation parameters was reduced, yielding improved results. In [21], the author used a seven-layered CNN network to train the dataset. A hierarchal Intrusion detection system is anticipated for SDNs in [22] which is trained on the Defense Advanced Research Projects Agency (DARPA) intrusion detection dataset using SVM. It combined the benefits of flow and packet-based IDSs to provide a high detection rate without affecting the network's performance. The authors in [23] used recurrent neural network (RNN) techniques to identify attacks and categorize them. A performance comparison was made of the RNN-based techniques and the non-RNN techniques. A network threat analysis strategy combined with long short-term memory (LSTM) is presented in [24]. To preserve the attack feature of input data, LSTM is presented to produce classifiers that categorize the attacks from the normal traffic. In [25], an RNN-based anomaly detection system is presented that, apart from capturing anomalies, generates flows to enable the network's dynamic access control.
Finding DDoS attacks in an SDN environment is carried out by using an advanced SVM algorithm, as given in [26]; the system is validated by using the Hierarchical Task Analysis method, which authenticates human errors to achieve certain results. The trending machine learning schemes-e.g., deep learning and hybrid AI techniques-provide greatly improved results compared to the conventional machine learning approaches. AI-based techniques have been found to be very beneficial when integrated with SDN architecture [27]. The author in [28] discussed numerous cyber-attacks and their detection strategies. The author proposed an embedded programming approach for the detection of denial of service attacks. Besides, the software engineering approach and AI techniques can enhance the detection strategies as they can detect zero-day attacks. Artificial intelligence has played an essential role in intrusion detection systems in recent years. In [29], the authors propose the Real-Time Sequential Deep Extreme Learning Machine Cybersecurity Intrusion Detection System (RTS-DELM-CSIDS) security model. The proposed model first defines the relevance of security aspects by ranking them and establishes a robust intrusion detection system based on the most relevant ones. The proposed approach had an accuracy of 96.22% in training and 92.73% in validation. The authors in [30] combined the features of a traffic flow and the power system's inherent physical laws to detect lousy data injection in smart grids. The generalized detection model focuses on identical characteristics to ensure the accuracy of unknown datasets and reduce the computational time. The results show an increase in the detection rate by 20% on average over the Chi-square test; furthermore, the approach filters the majority of Snort false alarms and solves the Security-Oriented Cyber-Physical State Estimation (SCPSE) observability problem. Deep learning techniques have been implemented to develop an anomaly-based network intrusion detection system, and the fully connected neural network model demonstrates desired outcomes with an advanced accuracy compared to previous techniques such as SVM, Random Forest and Adaboost [31]. CNN and LSTM-based detection systems are used to detect adversarial attacks in SDNs [32].
The deep learning approach has proved to have a great potential for the detection of malevolent activities. The deep learning-based GRU-LSTM (gated recurrent unit-long short-term memory) model is implemented in an SDN environment for the detection of network-based intrusions [33]. In [34], the proposed intelligent attack detection model is proved to be efficacious in terms of achieving state-of-the-art performance, with notably less time consumption than many existing models. Deep autoencoders are used in [35] to analyze the reconstruction error for the network's traffic records. Deep autoencoder and big data visualization techniques are used along with statistical analysis methods for vulnerability detection in [36]. In [37], the authors propose a hybrid detection system for the detection of cyber threats based on Spark machine learning and convolutional LSTM. They achieved an accuracy of 97.29% using the ISCXUNB dataset. The authors of [38] came up with a hybrid Intrusion detection scheme that combined the genetic algorithm along with the deep belief network for the detection of cyber threats, achieving an accuracy of 99%. In [39] a technique for the detection of malicious attacks in industrial IoTs is presented, leveraging deep autoencoders and deep forward neural networks and achieving a detection accuracy of about 99%. The authors in [40] present a machine learning-based attack detection approach in order to recognize significant threats in the IoT. The detection model consists of a hybrid technique implementing One Class Support Vector Machines (OCSVM), Self-organizing map (SOM), Gaussian Mixture Modelling (GMM) and Isolation Forest with a detection accuracy of 98%. The authors in [41] focus on creating an ensemble-based GRU model and LSTM for efficient attack detection. The model achieved 99% detection accuracy for attack detection in the IoT under the Message Queuing Telemetry Transport MQTT protocol. The authors of [42] implemented a bioinspired intrusion detection system for crossfire attacks. An average 80% detection rate was achieved with the proposed architecture. The study in [43] presented a deep learningbased cybersecurity architecture to identify threats in IoT networks. An accuracy of 95.5% was accomplished by this model, alongside a low false-positive rate. The nature of IoT traffic is comparatively different than other network types, as shown in [44], in which a Random Forest-based supervised machine learning algorithm is implemented which uses features extracted from the IoT traffic to identify the types of devices from the whitelist. In [45], the authors proposed a two-stage hierarchical network intrusion detection (H2ID) approach. The model achieves anomaly detection through a unique lightweight solution based on a multimodal deep autoencoder (M2-DAE), as well as attack classification, using soft-output classifiers. The research employed and validated the proposed model using the latest and up-to-date Bot-IoT dataset, containing four diverse attacks (i.e., DoS, Theft, Scan and DDoS), including unknown attacks. The proposed model is appropriate for privacy-preserving and distributed deployments. The authors in [46] presented an SDNenabled hybrid deep learning technique in order to identify bots in the Internet of Medical Things. They implemented a hybrid of CNN and CuDNNLSTM algorithms for threat detection. The authors in [47] used CNNLSTM algorithm for gesture recognition. The authors proposed that the frame-level classification of CNNLSTM is consistent with the cognitive perception of gestures.

Methodology
This section presents the complete methodology of the proposed work; i.e., the proposed network model, hybrid deep learning detection scheme and dataset description.

Proposed Network Model
SDN has been evolving as a technology of integrated network design in recent years. The data and control plane are separated in SDN's design, which allows improvements in areas such as simplification and flexibility. Furthermore, in the conventional design, every router in the network can only see the local state of the network; the lack of an overview of the complete network makes it complicated to autonomously produce a good potential defense approach compared to attacks. Instead, SDN has a global view of the network and central control functions, simplifying the gathering of network statistics. Besides this, the SDN proposes a separate way to reduce the risk of DDoS attacks; however, using SDN features and intelligent regulation to mitigate DDoS attacks remains a problematic issue.
We came up with an SDN-enabled DL-driven solution for the detection of threats in the Internet of Things (IoT) environment, as shown in Figure 1. The proposed framework comprises the application plane, control plane and data plane. The application plane is designed to run various applications to provide multiple services to the end-users. However, the application mechanisms are controlled by the control plane of the SDN to manage routing decisions, data transfers and traffic monitoring. The proposed framework is a part of the control plane. The SDN controller in the control plane is programmed to manage the whole network. The SDN controller is a central decision-maker and primary source of centralized control intelligence. The reasons behind putting the proposed model in the control plane are as follows: firstly, it is entirely programmable and can thus modify functionalities-it is capable of extending many networks on its data plane and provides solutions for heterogeneity between the linked IoT devices and SDN controller through open-flow switches; secondly, it can simply leverage the underlying IoT devices without exhaustion, making it an appropriate revolution for IoT. The proposed SDN-enabled DLdriven framework is cost-effective, as it is customized and centralized. The integration of IoT and SDN offers an exact solution for network traffic inspection to identify attacks and suspicious activities. All the decisions for underlying devices and networks occur here because the global network view is maintained here. Further, we have a data plane that comprises various IoT devices, sensors, smart devices and wireless technologies. The IoT can be extended at the data plane by the SDN control plane. Moreover, the implemented module can also be customized and can form a part of other SDN commercial controllers.

Proposed Hybrid Detection Scheme
A hybrid deep learning technique for efficient threat detection in an IoT environment that comprises CuDNNLSTM and CuDNNGRU is proposed. The hybrid intrusion detection model is placed on the programmable control plane of the SDN. The schematic representation of our detection module is shown in Figure 2. We trained and tested our system on hybrid algorithms with a reduced number of false positives, resulting in greater detection accuracy. The proposed model comprises multiple layers. DNNLSTM consists of two layers with a combination of 500 and 300 neurons. Further, we have added one layer of DNNGRU with 200 neurons. For all the layers except the output layer, we have used Relu as the activation function. However, Softmax is used in the output layer. The experiments were performed until 10 epochs were reached with 32 batch sizes to achieve efficient results. We have used the Keras framework for Python with the TensorFlow backend. This uses GPU processing and a Cuda-enabled version for improved performance. The complexity of recurrent neural network optimization emerges from the reliance of state computation on time. In RNNs-i.e., GRU and LSTM-the calculation of each step is delayed until the preceding step is complete. The dependencies of the RNNs limit their performance, resulting in a reduction of speed. This nature of the RNN architecture limits their applicability. CuDNN is a GPU-augmented library that allows multithreading, leading it to be quick and easy for high sequence modeling-capacity LSTM networks. Different memory blocks are recurrently connected and make LSTM layers, giving the model the ability to forget the old states and replace them with new information so that the system can learn to its maximum capability. In backpropagation, LSTM is widely used to solve the problem of gradient descent as well as for the predictions of time series. However, LSTM uses gating mechanisms for long-term dependency that enhance the flow of information. Furthermore, the quick multiplication of matrixes enhances the overall performance and is also carried out by LSTM. CuDNNLSTM can solve the sequential dependence problems of BasicLSTMCell [48]. A comprehensive architecture of the proposed hybrid deep learning model is shown in Table 1.

Dataset Description
The selection of a suitable dataset makes an essential contribution to the evaluation of the efficiency of an intrusion detection system. In the literature, researchers have employed various datasets, some of which include KDD99, KDD CUP, NSLKDD, UNSWNB15, CICIDS 2017 and several others for intrusion detection in IoTs. These datasets lack IoTsupportive features. Some hackers create/use webpages that scan for local IoT devices in order to take control of them. The hacker can use domain name system (DNS) rebinding as well as malicious scripts to discover and attack local IoT devices to take control of them [49]. That is the reason that we have selected a state-of-the-art dataset, CICDDoS 2019 [50]. The dataset chosen is based on a set of network flow features. The dataset is publicly available and is multiclass. The dataset consists of 78,283 instances, among which 66,510 are benign and 11,773 are instances of attacks. Our selected dataset consists of more than 80 traffic features and the most up-to-date and common attacks, which include DDoS, refection and exploitation attacks and some subtypes of these. The proposed work is only concerned with eight attacks. Table 2 shows the attack types and related information in detail. The main reason for choosing this dataset is to focus on the detection of attacks that lead to system exploitation.

Experimental Setup
Using Keras, we trained the proposed deep learning models with a version of Python, "Python 3.8". Furthermore, our PC server was assembled with TensorFlow and the CuDNN library based on the GPU to allow parallel processing. The experimental evaluations were done on a PC server equipped with Intel, Core i7-7700 HQ CPU @ 2.80 GHz processor, 16 GB of RAM and a 6 GB Nvidia GeForce 1060 graphics card.

Evaluation Metrics
To perform a thorough evaluation of the performance, standard evaluation metrics were implemented, including precision, recall, accuracy and F1-score. Moreover, true positive, true negative, false positive, Matthews correlation coefficient (MCC) and false negative values were calculated with a confusion matrix.

Result And Discussion
The outcomes from the complete assessment of the proposed technique of hybrid CuD-NNLSTM and CuDNNGRU are presented here. For comparison with the benchmarks, we have compared the proposed model with Cu-DNN and Cu-BLSTM as well as the state-ofthe-art hybrid Cuda-enabled deep learning detection techniques. To thoroughly illustrate the unbiased outcomes, 10-fold cross-validation was employed, as shown in Table 3. Average 10-fold results for the evaluation metrics were collected and are accordingly presented in various parts of this work.

Confusion Matrix Analysis
A confusion matrix shows the performance of the classification model on a set of test data. It is represented for either binary or multiclass data. It is beneficial for measuring accuracy, precision, recall and the receiver operating characteristic (ROC) curve. As shown in Figure 3, the proposed model identifies the nine different classes correctly.

ROC Curve Analysis
The ROC curve plots the visualized outcomes in order to compare the false positive and true positive rates. The degree of separability primarily shows the performance of multi-class classification issues, which is shown by the ROC. The plot of the ROC curve is between the TP rate and the FP rate. Figure 4 represents the ROC of our proposed model, which shows that our proposed model exhibits better performance in comparison to the other architectures.

Accuracy, Precision, Recall and F1-Score
Accuracy is characterized as the percentage of true labeled records. The detection accuracy also indicates the efficiency of an algorithm and its performance analysis. We have calculated the percentage of accuracy to create the graphs. The detection accuracy of the hybrid detection algorithms on the testing data is given in Figure 5. The proposed model outclassed the Cu-DNNGRU and Cu-BLSTM with a detection accuracy of 99.74% and a precision of 99.89%. Precision, also known as the positive predicted value (PPV), indicates the number of correctly identified records. The TPR, also known as recall, indicates the amount of accurately predicted records out of the total data. The F1-score characterizes the harmonic mean of the recall and precision. The recall and F1-score of the proposed algorithms are both 99.79%. Figure 5. Accuracy, precision, recall and F1-score.

FPR, FDR, FNR and FOR Analysis
We have further estimated other performance evaluation measures for a better estimation of our proposed work, which are the false positive rate (FPR), false discovery rate (FDR), false omission rate (FOR) and false negative rate (FNR). Figure 6 shows that our proposed model shows imporved rates of FPR, FDR, FNR and FOR of 0.528, 0.091, 0.198, and 1.138%. Further, Cu-BLSTM shows better results than Cu-DNNGRU.

TPR, TNR, MCC Analysis
An uncertainty matrix was used to get the values of TPR, TNR and MCC in order to perform a detailed evaluation as well as analysis. The proposed work calculated the classes from the confusion matrix. It is obvious that our proposed mechanism exhibited better TPR, TNR, and MCC outcomes. Figure 7 represents the TPR, TNR and MCC scores.

Comparison of Proposed Hybrid Technique with Hybrid DL Algorithm with CuBLSTM, CuDNNGRU
We developed a hybrid detection algorithm and implemented it on the dataset. Our detection scheme-i.e., hybrid CuDNNLSTM and CuDNNGRU-performed best in terms of all the considered evaluation metrics. We implemented CuBLSTM and CuDNNGRU as comparison algorithms on the same dataset, comparing the same evaluation metrics. The proposed hybrid algorithm gave the best results with a comparatively low testing time.

Comparison with Benchmark Algorithms
We compared our proposed algorithm with the current benchmarks. We evaluated the algorithms in terms of a comparison of some considered parameters. In [33], the NSL-KDD dataset was used for the detection leveraging of GRU-LSTM as a detection module, achieving an average accuracy of 87.90%, with a precision, recall and F1-score of 83.50, 77.90 and 80.60%, respectively. In [51], a hybrid DL detection scheme was made leveraging Cu(LSTM-CNN), which achieved an average detection accuracy of 98.60%, along with a precision of 99.37%, recall of 99.35% and F1-score of 99.35%. The algorithm had a testing time of 296 ms using the CICDDOS 2017 dataset. In [52], a hybrid detection framework was used, achieving an average detection accuracy of 98% with a precision of 91%. The proposed model showed an accuracy of 99.74% with a precision of 99.89%, with a recall and F1-score of 99.79% as shown in Table 4. The testing time of the proposed work was only 9.33 ms, which was less than the current benchmarks.

Speed Efficiency
The suggested hybrid deep learning model was analyzed regarding the total time taken. The two phases of analysis consisted of the training and testing phase, respectively. Training time is usually not considered as the training phase is done offline. However, the testing phase is of prime importance as the testing time truly depicts the efficiency and the performance of the model. Figure 8 of our paper shows the testing time of our model, which was only 9.33 ms, which means that the hybrid CuDNNLSTM and CuDNNGRU showed the best testing time and was computationally efficient. The confidence intervals of the testing times of Cu-DNNLSTM and CuDNNGRU, CuBLSTM and CuDNNGRU are shown in Figure 9. The proposed work used a 95% confidence interval.

Conclusions
With the advent of IoT, the risk of cyber-attacks has also increased to a great extent. As the IoT includes resource-constrained devices and the security of these devices is not an inbuilt feature, securing these devices is important. Traditional security mechanisms cannot be deployed immediately for their security due to the heterogeneous nature of these devices. Thus, the SDN paradigm is a promising solution to the securing of IoT infrastructure. This paper proposed a novel SDN-enabled hybrid DL-driven threat detection system for the IoT to fight advanced multivector cyber-attacks. Our proposed framework is a scalable, efficient and accurate solution. The proposed model obtains a detection accuracy of 99.74%. A comprehensive evaluation of the model is performed along with the evaluation of standard evaluation metrics, and we have made a comparison with the current benchmarks. The proposed mechanism of hybrid CuDNNLSTM and CuDNNGRU out-performs all benchmarks with regards to detection accuracy, precision and speed efficiency. Furthermore, the computational complexity of the proposed work is very low. The results of two Cuda-enabled algorithms-i.e., CuDNNGRU and CuBLSTM-were also compared to the proposed algorithm by implementing them on the same dataset, and their achieved results were beaten by the proposed hybrid algorithm. In the future, we aim to implement other deep learning classifiers to detect emerging cyber threats. In conclusion, the proposed work endorses the DL-driven framework for IoT ecosystems.


Nonparametric inference of stochastic differential equations based on the relative entropy rate

The information detection of complex systems from data is currently undergoing a revolution, driven by the emergence of big data and machine learning methodology. Discovering governing equations and quantifying dynamical properties of complex systems are among central challenges. In this work, we devise a nonparametric approach to learn the relative entropy rate from observations of stochastic differential equations with different drift functions.The estimator corresponding to the relative entropy rate then is presented via the Gaussian process kernel theory. Meanwhile, this approach enables to extract the governing equations. We illustrate our approach in several examples. Numerical experiments show the proposed approach performs well for rational drift functions, not only polynomial drift functions.

Introduction
Dynamical properties of complex systems such as complexity and sensitivity are ubiquitous, which are significant contents in the research of stochastic dynamical systems [1][2][3]. Less well understood, however, is how to better quantify dynamical properties of stochastic dynamics. The relative entropy rate is an effective tool to characterise the complexity and sensitivity of dynamical properties [4,5]. Traditional methods are affected by factors such as unknown governing equations. Owing to the decline cost of data storage and computation, as well as the development of machine learning, data-driven discovery methodologies have made great progress. Combining with data-driven discovery methodologies, it is possible to compute the relative entropy rate from time series data.
There exist many different forms in regard to data-driven methods, such as parametric and nonparametric approaches [6][7][8][9][10]. The recent sparse identification of nonlinear dynamics method, which proposed by Brunton and co-workers [11], is a scriptures of parametric approaches. Opper [12] employs the parametric techniques to compute the relative entropy rate. Whereas some complex systems are too complicated to model precisely via parametric representation. The nonparametric techniques, for example neural networks [13,14], Gaussian processes [15,16] thus are applied in data-driven modeling. They outperform the parametric methods for obtaining the data-driven models with accuracy and extensiveness, although the parametric methods provide concrete manifestation of models.
The relative entropy or Kullback-Leibler divergence has recently reemerged of machine learning as a cost function describing the difference between two probability distributions [17,18]. It provides a precise characterization for approximating underlying probability distribution by probability distribution from data. The Kullback-Leibler divergence has been applied to infinite dimensional probability measures of stochastic processes, such as probability inference [19] and optimal control problems [20][21][22]. The relative entropy rate [23], which is the long-term average limit of the Kullback-Leibler divergence, is a distance measure of two stochastic processes. It plays an important role in quantifying dynamical properties. Dupuis et.al. [4] discussed the uncertainty and sensitivity bounds of stochastic dynamics from observation data using the relative entropy rate. Pantazis and Katsoulakis [5] applied the relative entropy rate as a suitable information-theoretic object to analyze the sensitivity of the probability distribution of stochastic processes in regard to perturbations in the parameters of the complex dynamics. Techakesari et.al. [24] use the relative entropy rate to design hybrid system filters in the presence of (parameterised) model uncertainty.
In this work, we propose a nonparametric approach to learn the relative entropy rate from observations of stochastic differential equations with different drift functions. Current efforts are mainly focused on deriving a simple estimator for relative entropy rate via the Gaussian process kernel theory. Meanwhile, this approach enables to extract the governing equations. Our method requires only one sample data of the stochastic differential equation. It performs well for rational drift functions, not only polynomial drift functions.
The remainder of this paper is structured as follows. In section 2, we introduce the relative entropy rate of stochastic differential equations and the variational formulation. In section 3, we propose a nonparametric technique for the calculation of the relative entropy rate based on one path data of stochastic differential equations. Some numerical examples are presented in section 4, followed in section 5 by conclusion.

The relative entropy rate
In this work, we consider a stochastic differential equation for the dynamics of a d-dimensional diffusion process X t ∈ R d given by with initial data X 0 = x 0 ∈ R d , where g(·) ∈ R d is the drift function, the diffusion function σ(·) is the d × k dimensional matrix and B t is the standard Brownian motion in R k .
The generator A of this stochastic differential equation (1) is [25] for all ϕ is in Sobolev space where H is the Hessian operator with H = ∇∇ T . Thus, the probability density p(x, t) of the solution process X t satisfies the Fokker-Planck equation with initial condition p(x, 0) = δ(x − x 0 ), where A * is the adjoint operator of the generator A in Hilbert space L 2 (R d ), given by Here, H(σσ T ϕ) is interpreted as matrix multiplication of H = ∇∇ T and σσ T ϕ (note that ϕ is a scalar function). We call p the stationary probability density of the solution process X t if it satisfies the stationary Fokker-Planck equation A * p = 0.

The relative entropy rate for stochastic differential equations
The relative entropy or Kullback-Leibler divergence between the probability measures P g and P r of two solution processes for stochastic differential equation (1) with different drifts g and r is defined as Here, the diffusion matrix of two solution processes is both D(x) . = σ(x)σ(x) T , p g (x, t) is the probability density of solution process with drift function g and ||u(x)|| 2 A . = u(x) · A(x)u(x) for some positive definite matrix A. Suppose that the stationary probability exists. The probability density p g (x, t) then converges to the stationary probability density p g as t → ∞. Hence, we consider the relative entropy rate as follows In our work, we suppose that the drift r(x) and the diffusion D(x) are known, but the expression form of the drift g(x) is unknown. We, however, want to estimate the relative entropy rate via the observation data of the process X t with drift g(x) on a large time T .
Based on equation (6), the estimator of the drift g(x) and the stationary probability density p g (x) are crucial to the calculation of the relative entropy rate. In order to simplify the estimation problem, we assume that the diffusion D(x) = σ 2 I and drift g(x) satisfies a potential condition such as g(x) = −∇ψ(x).
Then the stationary probability density fulfills p g (x) ∝ e − 2ψ(x) σ 2 and one can estimate the density from observation data.
We will introduce a different way to calculate the relative entropy rate based on the variational formulation and generalised potential condition. To be specific, suppose that the expression of drift g(x) is Then the relative entropy rate (6) becomes Moreover, the stationary Fokker-Planck equation for drift g is defined as where p g (x) is the stationary probability density and the operator A * r , corresponding to known drift r(x), can express as

Variational formulation
In this section, we will give a brief introduction about the variational formulation. Here, assume that the specific form of drift g is unknown. We first estimate the drift g from the observation data using the variational formulation for the stationary Fokker-Planck equation (9) through relative entropy rate. Suppose that the stationary probability density p g (x) is given and we search for a estimator of the drift g(x) by minimizing the relative entropy rate (6). Introducing a Lagrange multiplier function ψ(x), we may derive the drift g(x) from the following Lagrange functional The Fokker-Planck operator A * g is defined in (4) for drift g(x) and the operator A * r is in (10). For more details see appendix.
Furthermore, making a variation of Lagrange functional (11) with respect to g(x) − r(x), one can obtain g(x) − r(x) = D(x)∇ψ(x). Inserting this result back into (11), the variational representation of relative entropy rate for a unknown potential ψ is where the generator A r is adjoint operator of A * r , (10) which satisfies ψ(x)A * p(x)dx = p(x)Aψ(x)dx. In addition, the explicit expression of generator A r is We next introduce the variational bound for the Lagrange functional (12) where equality is achieved while ψ = ψ * . We are surprised to discover that, from the perspective of variational bound, the minimisation of variational representation (12) can give us a estimator for the potential ψ and also compute the relative entropy rate According to the form of Lagrange functional ε g [ψ], we all know that applying the observation data which are the ergodic samples of the process with the drift g, one can estimate every potential ψ under the stationary probability density condition. The estimator of the relative entropy rate, then, can be obtained.
Subsequently, we give a simple proof for variational bound (13) as follows ≥0.
The first equation comes from the variational representation (12) and the second is due to the algebraic formula (a − b) 2 = a 2 − 2ab + b 2 . Owing to the relationship of generator A r and its adjoint operator A * r , as well as the usage of integration by parts, the third equation is established. Inserting (9) into it later, we obtain the second to last equation.
Before moving on to next section, let us discuss another stochastic presentation (14). Consider The dP r+Dψ /dP r represents the Radon-Nykodim derivative of two probability measures. According to (5) and (6), we see Since d(P g , P r+Dψ ) ≥ 0, we thus have The equality holds in (18) when P g = P r+Dψ . In next section, we will present a nonparametric estimator for the potential ψ and the relative entropy rate.

Nonparametric inference for relative entropy rate
In this framework, our goal is to construct an nonparametric estimator to the the relative entropy rate. We however know from the above theory of the potential ψ and stationary probability density p g is essential to calculating the relative entropy rate. Hence, we first need to a smooth estimator for stationary probability density p g , and then compute the potential ψ from data using a nonparametric approach via the variational representation (12).
There are many density estimation methods, among which the kernel density estimation is commonly used. The drawback of the kernel density estimation is nevertheless that it neglects the temporal ordering of observation data, as well as the time scale between them. Here, we employ the empirical distribution to replace the exact probability p g ,p The data x 1 , x 2 , · · · , x n are random, ergodic samples of the process with the exact probability p g . On the other hand, one usually build a parametric estimator of the potential ψ, which is represented by a finite set of basis functions. However, this representation of parametric method is not sufficient to express many functions, such as rational functions. We therefore work on a nonparametric estimate, which is a more general approach to these functions.
We now demonstrate the nonparametric estimate method. Introduce a penalty term firstly, which is selected as a quadratic form 1 2 k ω 2 k /λ k , where ω k are the weights corresponding to the basis functions of the parametric representation and λ k are hyper-parameters, to regularize the potential estimator due to a limited amount of observational data. We can also consider the penalty term from the perspective of pseudo-Bayesian. The exp{− 1 2 k ω 2 k /λ k } is viewed as a Gaussian prior distribution over weights ω k . Assume that the parametric of the variational representation (12) is ε emp [ψ ω ]. At the same time, the exp{−Cε emp [ψ ω ]} can be interpreted as a likelihood, where C represents the proportional weight between the penalty term and the observation data. The potential function ψ can thus be treated as a Gaussian process according to the above interpretation. Inspired by the viewpoint of Gaussian process, we will convert the parameter representation form into the kernel function form using the kernel trick, which makes the information for ψ expressed fully. To this end, we define where λ k and ϕ k are the orthonormal eigenvalues and eigenfunctions, respectively. This is also the covariance kernel of the prior of a Gaussian process about the potentials ψ.
The regularized functional of the potential function ψ can be defined as via the kernel approach. The K −1 (x, x ) represents the inverse of the kernel operator. In addition, the penalty term in (21) can be proved to be equivalent to the reproducing kernel Hilbert space norm of the drifts ψ defined by the kernel K. We will further derive a specific representation of the drift function estimator.
The variation of (21) with respect to ψ yields Multiplying both sides by the operator K, one obtains where the generator acts on the kernel function K as From above equations (22) and (23), we see that if we know ∇ψ(x) at all observation data x = x i , the potential function ψ(x) can be calculated for all x. The key to this work, however, is to evaluate the gradient of the potential ψ(x). We next compute ∇ψ(x) at all observation data points via performing the gradient of equation (22) and setting x = x i . Thus, there are a series of linear equations We so far obtain the drift function value ∇ψ * (x i ) at every point. Further, substituting into these drift function value, we can calculate the relative entropy rate

Numerical Experiments
We begin our verification of nonparametric estimate approach by describing a few experimental examples. Without special emphasis, we apply the radial basis function kernel where the length scale l is the hyper-parameter. In this section, we also show the nonparametric learning results of the drift function in order to further illustrate the advantages of this method.
Example 1. Consider a scalar stochastic dynamical system with the polynomial drift term  where W t is the standard Brownian motion and the diffusion function is σ(x) = 1. The known drift term r(x) = 4x − 4x 3 corresponds to a stochastic double-well system. Another drift function, however, which generates the samples through long-term observation is g β (x) = 4x − 4x 3 + ∇ψ(x), where ∇ψ(x) = −β(x 2 + 2x + 1) depends on β. The drifts g and r are equal when β = 0.
In the numerical simulation, we take the time step δt = 0.001, and use the Euler scheme to sample the stochastic differential equation with drifts g β in regard to the different values of parameter β. Here, we apply N = 10000 data points x k = X t k , uniformly sampled from a trajectory with the observation time length T = 10 5 . Thus the discrete times are t k = kτ for k = 1, · · · , N with τ = 10. Employing this data points, we can estimate the drifts ψ(x) and their gradients, and further compute the relative entropy rate in term of (14). The numerical results will later be presented in Fig.1 and Fig. 2.
In Fig.1, we compare the accurate and the learning results with regards to potential function ψ(x) for some β values and discover that the learning results have a good performance. As shown in Fig.2, the exact relative entropy rate and estimators corresponding to different values of parameter β are plotted. We can see that the exact relative entropy rate agrees well with the estimate result directly obtained from nonparametric method.
Example 2. Consider the transcription factor activator (TF-A) monomer concentration of stochastic differential equation in the gene regulation system [26] where the diffusion function is σ(x) = 1 and W t is the standard Brownian motion. The known drift term here is r(x) = 0, and another drift which generates the samples through long-term observation is g β (x) = ∇ψ(x) = β((6x 2 /(x 2 + 10)) − x + 0.4) depending on β. If parameter β = 0, the drifts g and r then are equal.
To further validate our method, taking the time step δt = 0.001 in the numerical simulation, and using the Euler scheme to sample the stochastic differential equation with drifts g β in regard to the different values of parameter β, we generate a trajectory with the observation time length T = 10 5 . Here, we utilize N = 10000 data points x k = X t k , uniformly sampled from this generated trajectory. Thus the discrete times are t k = kτ, k = 1, · · · , N with τ = 10. Employing this data points, we can obtain the potentials ψ(x) and their gradients, and meanwhile compute the relative entropy rate in term of (14).  As shown in Fig.3 and Fig.4, the comparison regarding the learning and accuracy results of the drift function ψ(x) are given, as well as the exact relative entropy rate and estimators for different values of parameter β are plotted. We can see that the evaluation of the drift function ψ(x) is pretty and the exact relative entropy rate agrees well with the estimate result directly obtained from nonparametric method.
Example 3. In order to show the superiority of our method, we also consider the trigonometric polynomial function Here, W t is the standard Brownian motion and the diffusion function σ(x) = 1. Taking the known drift term r(x) = 0, and another drift which generates the samples through long-term observation g β (x) = ∇ψ(x) = β(sin(X t ) − sin(X t ). 3 ) depending on β. If parameter β = 0, the drifts g and r then are equal.
We take the time step δt = 0.001 in the numerical simulation, and then apply the Euler scheme to sample the stochastic differential equation with drifts g β in regard to the different values of parameter β, and generate a trajectory with the observation time length T = 10 5 . Here, we utilize N = 10000 data points x k = X t k , uniformly sampled from this generated trajectory, so that the discrete times are t k = kτ, k = 1, · · · , N with τ = 10. Employing this data points, we obtain the potentials ψ(x) and their gradients, and compute the relative entropy rate in term of (14). We show the results in Fig.5 and Fig.6.
The comparison regarding the learning and accuracy results of the drift function ψ(x) are given in Fig.5, as well as the exact relative entropy rate and estimators for different values of parameter β are plotted in Fig.6. We see that the evaluation of the drift function ψ(x) is pretty and the exact relative entropy rate agrees well with the estimate result.

Conclusion and Discussion
In conclusion, we have presented a nonparametric technique to learn the relative entropy rate which is applied to describe dynamical properties. The study of dynamical properties of systems is significant for stochastic dynamical systems. Here, we offer a good methodology for their study to learn from time series data. Moreover, the nonparametric method not only provides a precise estimation for our functions and the relative entropy rate, but also adapts to a wider range of functions types, such as rational function, compared with parametric approach. This performance has been well demonstrated in examples.   In addition, this work motivates a number of future extensions. Our framework can be extended in other Markov processes, including Markov chains or Lévy processes. They would be interesting in realistic application. On the other hand, the stationary density is worthy of attention because of the need for a long time observation. We can generalize this issue with finite time window T and evaluate further the marginal densities p g (x, t).
Moreover, under the induced probability measure Q by Girsanov theorem, Y t also satisfies the stochastic differential equation where B Q t = t 0 u(s)ds + B t is a Brownian motion with respect to the induced probability measure Q. Then by weak uniqueness of the solutions for stochastic differential equation (1) and (33), the likelihood function can be represented as To this end, we could use Itô formula to represent the stochastic integral as the a Riemann integral and the relative entropy is where D = σσ T and p g (x, t) is the probability density of the stochastic differential equation (1) with drift vector filed g. Assuming that p g (x, t) converges to the stationary density p g (x) for t → ∞, we shall consider the relative entropy rate D(P g , P r ) = 1 2 Adding the Lagrange multiplier term, equation (36) becomes our optimal objective functional (11).