The Ucd Casl Sensetile System Joseph R. Kiniry, Vieri del Bianco and Dragan Stosic UCD CASL: Complex and Adaptive Systems Laboratory and School of Computer Science and Informatics, University College Dublin, Belfield, Dublin 4, Ireland, kiniry@acm.org, vieri.delbianco@gmail.com, and dragan.stosic@gmail.com Abstract The UCD CASL SenseTile System is a large-scale, general-purpose sensor system installed at the University College Dublin in Dublin, Ireland. Our facility provides a capability, unique in the world in terms of its scale and flexibility, for performing in-depth investigation of both the specific and general issues in large-scale sensor networking. This system integrates a sensor platform, a datastore, and a compute farm. The sensor platform (called the SenseTile Unit) is a custom-designed, but inexpensive sensor platform. Each unit is composed of one or more SenseTile Sensor Boards paired with a SenseTile Processor Unit, the latter of which includes everything from PDAs to powerful touchscreen-based portable computers. Communication between the Sensor Board and the Processor Unit takes place over a USB bus using a streaming packet-based protocol. There are over a dozen sensors on the SenseTile Sensor Board itself, and new sensors are added either using expansion slots on the SenseTile Sensor Board, or by adding them directly to the USB bus. The datastore is a multi-terabyte scale scientific datastore into which sensor data flows, and in which online and offline scientific computation of sensor and other scientific data takes place. The compute farm is a large-scale Linux, Solaris, and Mac OS X-based compute farm used by scientists for these online and offline scientific computations. Our facility aims to provide a scalable and extensible infrastructure for performing in-depth investigation of both the specific and general issues in large-scale sensor networking. Introduction The complexity of our platform requires the need to strive for formal descriptions each hardware/software component separately and behavior of their complex interdependencies, in order to produce executable specification. This approach has been considered not feasible nor convenient if applied to our case since it does not respect some of the requirements: first of all, we want to enhance the protocol specification incrementally and we are not able to provide a complete specification from the beginning, hence, a properly defined specification is not available in advance. Secondly, because of hard time constraints, and the initial unavailability of the custom board, we needed to progress concurrently with all the development tasks. To tackle the complexity of the concurrent development tasks, the formal model of the protocol was used as a focus point that led all the other development tasks. On the other hand, implemented in VHDL-AMS, formalism already exists in SensorTile Sensor Board and represents a central logic part of the embedded system. The main idea of our concurrent approach can be understood in the following way: If we are able to simulate the formalism on the board and establish a formal link between the SenseTile Simulator and protocol specification, then we could develop a rest of the system in the absence of the board. The protocol to specify has been divided in various (thin) layers, each of the layer has been specified with a different lightweight approach: some of the layers have been specified formally, while others have been specified in an unprecise way. The formal specifications have been used to check at run time the correctness of the Sensor Board, the driver and the SenseTile Simulator. The formal specifications have also been used to automatically generate a test suite to verify the driver and the simulators, and eventually to verify the specification itself. An hand made test suite has been used to verify the driver and the simulators as well. The generated and hand made test suites have been used together, complementing each other. On the basis of the above we can conclude: The protocol model is itself an executable stream simulator that can be used to develop new SenseTile user applications without having the SenseTile hardware at all. Consequently, from this single specification, we are able to test that the SenseTile hardware communicates as expected, that our SenseTile Simulator communicates as expected, and simulate the SenseTile protocol stream itself. The next two sections presents a brief description of the protocol and simulators. Data stream and protocol SenseTile Sensor Board and SenseTile Processor Unit communicates via an Universal Serial Bus (USB) interface. A proprietary protocol is used on top of the USB serial channels, the protocol is specified by the FTDI the manufacturer of the USB controller chip used in the SenseTile Sensor Board , the FT2232H. The proprietary protocol enables the control and management of some of the functionalities in FT232H chip (such as internal EEPROM read and write, reset of the chip, etc.), as well as the definition of the communication protocol and properties to be used in the asynchronous channels (input and output channels) provided by FT232H. These functionalities are accessed via an Application Program Interface, the API is provided by a driver developed directly by FTDI, which is available for various systems (Linux 32 and 64 bits, Mac OS, Windows). Finally, a custom protocol has been developed to manage the entire SenseTile Sensor Board, built on top of the serial channels provided by the API.The custom protocol is meant to be used to read sensor data observations, enable or disable sensors, configure on-board components (as the Field-Programmable Gate Array and the micro processor); the protocol main function is to read sensor data. The protocol is asynchronous and packet based. A custom medium-level Java driver creates and parses the SenseTile Sensor Board streaming communication packets. The driver is formally specified, validated and verified with rigorous unit testing, both hand made and automatically generated. Because of this process and combination of technologies, we are able to verify a real SenseTile and a simulated one as well. A detailed description of the packet structure is given in article-(Joe/Vieri) paper. On simulators Simulators can be used to test parts of the system, to minimizing their dependencies: a simulator can be used by upper layers, with no need to provide the functionalities of the lower layers. The simulators have been built reflecting the software abstraction layers defined for the driver. The driver API is splitted in two abstraction layers: the general high level interfaces, that expose the main functionalities of the board and the main contents of the packets, and the lower level implementation that parse the data streams in and out the board, meant to translate the higher level instructions and data in properly formed packets. The high level simulator implements the interfaces providing the methods to deal with an abstracted Sensor Board: the simulator knows nothing about the details of the real format of the binary data streams. The low level simulator (SenseTile Simulator) is capable to rebuild the Sensor Board data streams: the in and out data streams are built exactly as the sensor board is expected to be able to parse or generate. The SensorTile Sensor Board are custom-designed in VHDL-AMS. Like many hardware-based systems, to write new software for or against the SenseTile architecture one either uses the actual hardware or one runs a SenseTile Simulator. But this simulator emulates a piece of hardware, one would like to know if the simulator actually simulates the hardware. We have developed an approach through which we refine the VHDL-AMS specification up to the formal BON specification language, and from this specification we generate an executable, functional model-based specification in the JML language. A detailed description of the transformation from VHDL-AMS to BON is given in article-(Joe/Dragan) paper. During the development of the SensorTile Simulator have been essential, since the physical board was not available: we needed at least to remove the dependencies over the real board to execute the driver implementation. Simulator have been built concurrently with the specification, the driver implementation, and the tests. Run the system The approach proved itself effective, at the point that, when the board has been finally released, only one small defect has been found in the driver, while the errors and not agreed changes introduced in the board and in the protocol it implemented, have been discovered immediately, with no additional effort.Besides, the simulators are able to feed with correct data the rest of the system.