A framework for Hardware In the Loop simulation ... - Semantic Scholar

HILAC: A framework for Hardware In the Loop simulation and multi-platform Automatic Code Generation of WSN Applications Mohammad Mostafizur Rahman Mozumdar∗ , Luciano Lavagno† , Laura Vanzago‡ , Alberto L. Sangiovanni-Vincentelli∗ ∗ University

of California, Berkeley, Electrical Engineering & Computer Sciences, 545H Cory Hall, 94720, CA, USA Email: {mozumdar, alberto}@eecs.berkeley.edu † Dept of Electronics, Politecnico di Torino, Italy Corso Duca Abruzzi 24, 10129 Email: [email protected] ‡ STMicroelectronics Milan, Italy Email:[email protected]

TOSSIM [13] for debugging of TinyOS application, OmNet and NS, fall into two main categories. One is very platformand OS-specific (such as TOSSIM), while the other includes generic network simulators (such as OmNet, NS, etc). Both have significant drawbacks when it comes to complex application development. The first group makes it very expensive to port an application to a different platform (e.g. from TinyOS [14] to a ZigBee compliant platform). The second group still leaves a lot of detailed platform-dependent code to be developed and debugged. Integrated use of a network simulator followed by a platform simulator is the most commonly used path, but still requires one to port code between a number of environments. Moreover, in case a bug is found at the end, one has to resort to low level debugging, which is extremely time-consuming and has to manually maintain the consistency between the various code levels. EmStar [9] tries to address this last problem by executing the application in a simulation-like environment, but using real-world I/O. It connects the simulation to the sensors and radios of a real-deployed sensor network and thus helps bridge the distance between simulation and the physical world. However, it still does not address the issue of multi-platform code development. Our contribution is aimed at easing platform independent WSN application development without compromising on the efficiency of the final implementation. We propose a model based framework (HILAC) built primarily on top of the MathWorks tool chain. Application developers are able to model applications using Stateflow/Simulink [23] and perform HIL simulation by interacting with the real sensor node. To remove platform dependency from Stateflow/Simulink modeling, we developed a set of generic interfaces (for sending/receiving packets and also for acquiring data from different sensors) and an event mechanism, which ultimately allows developers to

Abstract—Hardware and software platforms for Wireless Sensor Networks (WSNs) are almost as diverse as their application areas, with very limited standardization. Moreover, heterogeneous programming abstractions put high barrier in application development and there is hardly any support for application debugging, except for a few blinking LEDs. Similar problems have been solved in application domains that have similar cost constraints, such as automotive, by the use of model-based design. We address the lack of model-based design tools for the WSN domain by providing a framework (based on Simulink, Stateflow and Stateflow Coder) in which an application developer can model a WSN application by using Stateflow constructs and then use a single model to perform multi-platform Hardware-In-theLoop (HIL) simulation and platform-specific application code generation.

I. I NTRODUCTION Platforms for Wireless Sensor Networks (WSNs), including processors, sensors, radios, power supplies, operating systems and protocol stacks, are almost as diverse as their application areas, with only a few standards (such as ZigBee [22], 6LoWPAN [11], etc) that address mostly the lower levels of the radio protocol stack, and not the application API. Further more most of the available sensor nodes on the market (such as Mica [21], Tmote Sky [18], MotionBee [20]) only provide a few on-board blinking leds for debugging. Although WSNs have experienced great advancements in last decade, still application development in this domain is quite challenging. There is a lack of tools that can provide modeling, HardwareIn-the-Loop (HIL) simulation and automatic code generation for multiple platforms from a single high level abstraction. Just like other embedded systems, WSN applications need to be verified functionally before being implemented on the actual platform in order to discover as many bugs as possible at a high level, where fixing them has a lower cost. The available functional analysis packages, such as

978-1-4244-5841-7/10/$26.00 ©2010 IEEE

88

SIES 2010

#    $%&

         !
"  #    $%  &'


 

  

   

    

       

 !  "


    

  






    

Fig. 1.




A high level view of platform independent HIL simulation and code generation

specify applications in Stateflow having no detailed knowledge of target software systems. After HIL simulation, HILAC can generate the complete application code for ZigBee and TinyOS based platforms from a single Stateflow application model. In this paper we used the ZigBee stack provided by Ember [7] as an example of target for code generation that is very different from TinyOS. Adding more supported platform is quite fast and requires writing some library software and changing some scripts. A high level view of the framework is shown in figure 1. The WSN algorithm is modeled in Stateflow and this single model is used for multi-platform HIL simulation and also for code generation. The application developer can thus use the broad variety of debugging and analysis tools provided by MathWorks, such as animated state chart displays, scopes, plots, as well as exploit a large number of available predesigned Simulink blocks. Our proposed framework is a substantial extension of the work described in [2] where we proposed a framework for modeling, simulation and automatic code generation for multiple WSN platforms based on MathWorks tools. One of the obvious extensions of this work would be to support HIL simulation and also to generate code from the same high level model (for TinyOS and ZigBee stack). In [2], we required to manually change the Stateflow model to prepare it for the code generation phase. In our new framework, we solve this issue and propose a more automated solution (using the techniques described in [3]) and model a realistic application. In [12], the authors proposed a HIL simulation tool for TinyOS called TOSHILT. They argued that HIL testing can reveal design flaws and software bugs that become evident

978-1-4244-5841-7/10/$26.00 ©2010 IEEE

only when the code is executed on the target WSN platform. In [6], a graphical development and simulation environment for TinyOS-based applications, called Viptos, is described. Viptos provides graphical development and interrupt-level simulation of actual TinyOS programs, with packet-level simulation of the network. It also allows the developer to use other models of computation available in Ptolemy II [5] for modeling various parts of the system. To model an algorithm using Viptos, the users are bound to code it for TinyOS, which implies that the user should have sufficient knowledge of TinyOS. In [15], the authors propose a gdb based source level debugger only for TinyOS. In the macro/functional programming model, users do not handle each individual node, but rather handle the network application as a whole. Hence application developers specify tasks at a higher level, hiding embedded system details and node communication protocols. Macro/functional programming based modeling approaches are described in EnviroTrack [1], Kairos [10], Regiment [16] and aTaG [4]. All these approaches suffer from a basic problem: non transparency. The code that ends up being executed is very far from the source. On the other hand, our approach handles node level programming using a platform independent abstraction which allows the developer to design and debug the behavior of the application more precisely. In all the approaches above, the authors attempted to address scenarios like high level application modeling, HIL simulation, debugging or code generation separately mostly for a specific platform. But none of them is capable of performing application modeling, HIL simulation and code generation from a single high level abstraction that serves for multiple platforms.

89

SIES 2010


 

  
   
 
  
 
  

 
 

  
  




 % &
 '

  
 



 



  
   

 

  " # 
 
    $ 
  
 

  
! 

    !  





 
  




!



 


  
 
! 
"#


 

 
 


  
 
! 
"  #

Fig. 2. Design flow of platform independent Hardware-In-the-Loop simulation and code generation for WSN applications

To the best of our knowledge, this is the first time that a framework of this sort has been developed and tested. II. P LATFORM I NDEPENDENT M ODELING F RAMEWORK The complete framework for platform independent application modeling, hardware-in-the-loop simulation and automatic code generation for multiple platforms is depicted in figure 1 while figure 2 shows the design flow based on it. The WSN algorithm (application or middleware) is initially modeled as a Stateflow block. While modeling, the application developer uses Stateflow constructs (such as states, transition diagrams, events, etc.) which are independent of the specific APIs and programming languages (such as TinyOS or implementation of ZigBee stack), and uses a set of library functions to interact with sensors. The radio and the sensors physically reside on the node, and are transparently accessed • either as prerecorded matlab streams of data, in the initial phases of design, • or using a serial cable connection to the physical node, when hardware-in-the-loop simulation is used. This algorithm block is connected to other Stateflow / Simulink blocks that generate events from other software or hardware components of the platform (such as CLK for periodic scheduling and PKT for radio data reception). In order to transparently support HIL simulation, these events can come both from Simulink models or from the actual node over a serial connection. The Stateflow model can be refined repeatedly, in order to tune the functionalities and performance of the algorithm as shown in figure 2. At the end of development, the same model also serves as an input for the code generation phase. The first step is to generate platform independent ANSI C code from the Stateflow algorithm model

978-1-4244-5841-7/10/$26.00 ©2010 IEEE

using Stateflow Coder. The next step is to adapt the generated ANSI C code to the target platform. Target Language Compiler (TLC) [24] scripts are used for this purpose. TLC provides mechanisms to generate platform specific code by extracting sections (such as includes, defines, functions, etc) from ANSI C code and by adding custom code for the target platform. Here the library functions that were used in the functional simulation or during the HIL phase are replaced with platform dependent implementations. By using TLC scripts (which are also called System Target Files), the application developer now can generate automatically for example a TinyOS application (composed of .nc, .h and makefiles) or an Ember ZigBee application (composed of .c, .h and configuration files), and then can compile and execute these applications for the target platform without any modification. Note that in this scenario we distinguish two roles, in general belonging to different companies: • Application developers, who know the requirements of the application domain and can ignore the details of the various platforms. • Platform developers, who write libraries of code and the corresponding TLC script for a specific node hardware, protocol stack and OS. This follows the platform-based design methodology [8] [17]. In this work, we effectively create a Stateflow and Simulink -based system platform for WSN applications that is more abstract and thus leads to more reusable applications, than TinyOS or specific commercial custom platforms (e.g. Ember ZigBee). This reusability does not incur almost any penalty in terms of code size or execution time, essentially thanks to the use of TLC scripts to rewrite and customize the automatically generated code. III. H ARDWARE I N THE LOOP SIMULATION

Fig. 3.

Setup for HIL simulation

Figure 3 depicts the setup for HIL simulation. It includes mainly two entities: the stub code executed on the node

90

SIES 2010

and the Simulink / Stateflow block accessing this stub via a serial (e.g. RS-232 or usb) cable. The stub contains basic platform-dependent code to join or interact with a ZigBee or TinyOS network, without any application-specific part. When the stub receives a packet from the network, it stores the packet locally and at the next request from the Stateflow model residing on the developer workstation (in PC), it transfers the packet payload over the serial cable. In the same way, when the stub receives a packet payload from the Stateflow model, it constructs the actual packet and transmits it to the network. On the PC side, a Stateflow block implements the WSN algorithm and interacts with the stub for reading sensors and also for sending or receiving packets to/from the network. Other Simulink / Stateflow blocks modeling, for example, sensors, actuators, and radio power control support smooth separation between the application model and HIL components. In the following, we will use as an example of three axis accelerometer provided by a hardware platform from STMicroelectronics [20]. We will use it for HIL simulation in two examples platforms that are very different from each other: TinyOS and the ZigBee compliant Ember stack. But the same methodology can be used to extend the framework to any number and kind of WSN platforms.

master (the PC). This is similar to the USB protocol, but can be implemented on top of any serial connection (USB, RS232, etc.). The protocol uses the following byte coding for interacting with the Stateflow model on the PC: • SENDPKT (50): When the stub receives this value at the starting of a new transaction, it knows that it is going to receive a packet payload from the PC. The next byte should be the length of the payload followed by consecutive bytes of the payload. After receiving a complete packet, it constructs the physical packet and broadcasts it to the network. • GETPKTCNT (60): After receiving this value from the PC, the stub sends a byte which contains the number of currently stored received packets. • GETPKT (61): After receiving this value, the stub transfers the received packet to PC. Afterwards, it removes the packet payload from the queue. When the stub receives a packet from the network, the stub stores it in the local queue and then transfers it to the PC by using transactions GETPKTCNT and GETPKT. • GETACCELXAXIS (75): After receiving this value from the PC, the stub calls LIS3LgetX.get to read the X axis value of the three axis accelerometer. This is an async command whose result is returned by calling the LIS3LgetX.getDone event handler. Inside this event handler, the stub transfers two consecutive bytes of the result to the PC. Note how a split-phase call (get/getDone) on the TinyOS side is viewed as an asynchronous call on the Stateflow side, where the application receives the result as a callback also when the target is a ZigBee node (the converse is also possible, i.e. a synchronous call in StateFlow being handled transparently as split-phase in TinyOS). The application programmer can thus ignore the tasking model and other architecture details of the target platform. Our HIL and code generation framework takes care of generating the most efficient implementation. • GETACCELYAXIS (76) and GETACCELZAXIS (77) perform the same for the Y and Z axis.

A. Node Stub In our example, we will perform HIL simulation with two different platforms, hence we implemented two different stubs, one for TinyOS and one for a ZigBee compliant platform. Each stub contains device drivers and other basic software to support the underlying platform. In addition, it includes a simple serial protocol implementation that is used to communicate with the Stateflow blocks on the PC. This protocol is used for reading data from sensors and also for sending or receiving packets to/from the network respectively. 1) Stub Implementation on the TinyOS platform: The programming model of TinyOS is based on components. In TinyOS, a conceptual entity is represented by two types of components : Module and Configuration. A component implements interfaces. The interface declares the signature of the commands and events which must be implemented by the provider and user of the interface respectively. TinyOS uses a split-phase asynchronous API calling mechanism. TinyOS applications are written in nesC, which is an extension of the C language. A skeleton of the stub implementation in TinyOS is shown in example 1. The main interfaces are listed below:• SerialFrameComm: implements a byte transfer-level serial protocol between the stub and the Stateflow model. • LIS3LHiddenInit, LIS3LgetX, LIS3LgetY, LIS3LgetZ: acquire data from a three axis accelerometer. • AMPacket, AMSend, SplitControl, Receive: send or receive packets to/from the network. The SerialFrameComm.dataReceived event handler is called when the stub receives a single byte from the serial line. To maintain smooth communication, the serial protocol is implemented using several transactions, all initiated by the

978-1-4244-5841-7/10/$26.00 ©2010 IEEE

Example 1: Skeleton of the stub implementation in TinyOS module StubNodeTinyOsM { uses interface SerialFrameComm; ... } implementation { .... // Sending X axis value of the accelerometer to PC event void LIS3LgetX.getDone(uint16_t xAxisValue, error_t success){ call SerialFrameComm.putData((uint8_t)xAxisValue); call SerialFrameComm.putData(xAxisValue>>8); return; } // Sending Y axis value of the accelerometer to PC event void LIS3LgetY.getDone(uint16_t yAxisValue, error_t success){ //Similar as LIS3LgetX.getDone implementation } // Sending Z axis value of the accelerometer to PC event void LIS3LgetZ.getDone(uint16_t zAxisValue, error_t success){ //Similar as LIS3LgetX.getDone implementation } // Impl of Serial protocol SENDPKT,GETPKTCNT,GETPKT,GETACCELXAXIS,.. async event void SerialFrameComm.dataReceived(uint8_t data){ ..... switch(data){ case 50: //process SENDPKT command of serial protocol break; ...... } return; } ..........

91

SIES 2010

based on the same protocol as in the TinyOS case. In the Ember ZigBee implementation, when a node receives a packet, then emberIncomingMessageHandler is called. After receiving a packet from the network, the stub stores the packet payload (and then transfers it to the PC with transactions GETPKTCNT and GETPKT). When a packet payload is received from the PC (during SENDPKT), the stub constructs a ZigBee packet and broadcast it to the network by calling emberSendBroadcast. To access sensor data from accelerometer, the stub uses APIs like getAccXAxisValue, getAccYAxisValue and getAccZAxisValue during transactions GETACCELXAXIS, GETACCELYAXIS and GETACCELZAXIS.

}

2) Stub implementation on the Ember platform: ZigBee is a specification that enables reliable, low power, wirelessly networked, monitoring and control products based on an open global standard. It includes mechanisms for forming and joining a network, a CSMA mechanism to wait for a clear channel, as well as retries and acknowledgment of messages for reliable communication between adjacent devices. The ZigBee specification supports networks with one coordinator, multiple routers, and multiple end devices within a single network. Details of the ZigBee specification can be found in [22]. ZigBee is different from TinyOS, in that it specifies only the protocol, not the concrete API, nor the scheduling and inter-task communication model. Several implementations of the ZigBee stack are available on the market (e.g. from Texas Instruments, Ember Corporation, Freescale, etc.). We will describe our stub implementation by using the Ember stack [7]. The stub implementation for HIL simulation is an end device type, so it joins a ZigBee network formed by the coordinator. A skeleton of the stub implementation is shown in example 2.

B. HIL simulation framework in Simulink/Stateflow

Example 2: Skeleton of the stub implementation in the Ember ZigBee stack #include .... // Global and ZigBee specific variables EmberEndpointDescription PGM ..... // Entry point of an Ember ZigBee application int main(void) { halInit(); // Initialize the hardware abstraction layer INTERRUPTS_ON(); // Allow interrupts emberInit(...); // Initialize the Ember ZigBee stack setLis3lParameters(); // Initialize accelerometer parameters while(TRUE) { // Main application loop halResetWatchdog(); emberTick(); processSerialInput(); // Implementation of Serial protocol applicationTick(); // WSN application code } } // Read X axis: high byte