SSIART – Smart Sensor Inter-Agency Reference Test bench

1. SSIART – Smart Sensor Inter-Agency Reference Test bench Activity Presentation October 2010 Jean-François Dufour ESA/ESTEC/TEC-EDD

2. Rationale of the activity • In 2010, the CCSDS SOIS Wireless Working Group was searching for a way to produce fair comparisons between several wireless technologies for sensors (e.g. PHY/MAC technologies, routing algorithms, power consumption, frequencies, responsiveness…). • The available solutions, e.g. internal developments and simulations, do not offer the required comparative framework because they are either highly implementation-dependent or data is simply missing for a proper simulation. • At the same time, ESA and NASA were looking for collaborative activities in the field of wireless communications. • This led the group (made of ESA, NASA and industrials) to propose a collaborative activity that would result in solving this precise issue. • The Smart Sensor Inter-Agency Reference Test bench (SSIART) shall provide the space Agencies and the Industry with a reference platform to test wireless sensor technologies in real representative applications, while promoting them at the same time.

3. SSIART Goals Objectives: • Compare different WSN RF systems • Need to compare e.g. Tx power, cavity frequency responses, inter-cavity link budgets, data rates, attenuations, signal distortion and effects of multi-path, EM compatibility, responsiveness to failure, to interferences and to environment modifications, effects of antenna diversity, power consumption, impact of routing, etc. • The comparisons shall also help the trading-off and selection of wireless technologies based on application-specific requirements. • Use the device in real-life situation • In other words: a device shall provide useful data and promote the technology • Share the test bench and test data with Agencies and the Industry • Make designs, implementations, test environments and test results available

4. SSIART definition What SSIART is: • A set of shared testing environments and test plans; • A database containing the results of the tested technologies and environments; • A suite of configurable wireless sensor network device designs and implementations targeting the space industry, partly customizable and partly frozen;

5. 1 - SSIART reference environments • Standardizing testing environments allows a coherent comparison of different wireless systems under test; • It is suggested to have at least one reference environment in each space Agency, which environments are also to be made “available” to the Industry (tbc). • The framework has also to allow the addition of new reference environments from the Agencies and the Industry. • Examples of possible reference test environments: • Intra-spacecraft: • Venus Express (ESA), Orion Equip.bay & Habitat HBU (NASA) and commsat (industrial) mock-ups • ISS: • Colombus (ESA) and tbd (NASA) mock-ups • Ground testing and verification: • Reference vacuum chambers, large solar simulator…

6. 2 - SSIART test plans and database • Wireless technologies tested in the comparative environments are to be shared among partners through a shared (open or protected tbd) test database • It shall contain at least the detailed test plans (including physical configurations of nodes and environments) and the results based on a predefined template. • A list of the “to-have” wireless characteristics to test/evaluate, as well as template test plans is to be provided. • There will be opportunities to build tools that help provide an effective comparison between the technologies and that may help in trading-off and selecting the right wireless technologies based on the provided application-specific requirements.

7. 3 - SSIART implementations • SSIART is also a semi-customizable reference sensor system that • Allows to concentrate only on the wireless components; the sensing, power and control being already developed and available. • Reduces the time and effort needed prior to the actual testing. • Offers a fully functional sensing platform that can be used in ground testing applications. • It is based on two physical parts: • The sensing board hosts the sensing, power, control and physical interface components. It is a frozen (configuration-managed) package that comprises a PCB layout, a bill of material, a software package, an interface document (SW and HW) and assembling guidelines. • The wireless board hosts the radio components to be tested. This generally includes the wireless radio and the antenna system, but may also include a dedicated microcontroller (e.g. for MAC software or for more advanced features like routing protocols). This board has to be designed and implemented for each new wireless technology. The board then seamlessly stacks up onto the sensing board. Its design has constraints but is mostly customizable.

8. 3 - SSIART implementations • Other secondary items are also necessary: • Network coordinator board • Should also be partly customizable in order to support the different wireless technologies (e.g. standard, frequencies…), very probably the same way as the sensor board (stacked pcbs); • Includes the interface definition to the PC/OBC. • Debug/programming board for the sensing board • Board to program and debug both the sensor and the coordinator devices; • Also includes the related cross-platform deployment guidelines. • Debug/programming board for the wireless board • Debugs and programs the wireless board; • Embedded test software modules and framework (middleware)

9. Starting SSIART Preparation Phase 1 • Identification and agreement on the “shared” test environments • Identification of wireless characteristics to include in test plans • Identification, elaboration and agreement on test plan templates • Design of the collaborative data management system (database) • Evaluation of the need for a fair comparison tool • Preliminary design of all necessary devices + software architecture • …? Preparation Phase 2 • Basic characterization of the test environments (including CAD) • Establishment of the collaborative data management system • Detailed design of all necessary devices + software architecture • Manufacturing, verification and characterization of designs and devices • Preparation and dry run of the entire testing process • …?

10. Update 2011.05.19 • RB/RW might have issues in justifying the costs and efforts to implement another platform (HW & SW) than the modular one they have • Without the “real-world application” objective, a sensorless system with synthetic data would be enough to achieve the other objectives. • We could agree on a predefined bill of material for the most critical components, but leave the design and/or layout free for physical implementation. We still would need standardized interfaces to the radio boards. Or not? Actually, we could leave the radio board design also free. The DUTs only need to be similar in a single reference environment. • If ESA wants to test a radio device in a NASA-based test environment (which include NASA-based test devices/platform), it needs to implement a new board compatible with NASA’s interfaces • ESA would need to have a NASA-based test platform to test the board • It would simplify to not have to rewrite any drivers • Keep the platforms static for a precise • Questions • Does having a different form-factor physical hardware have any impact on the results? (e.g. current, multi-path…) • Can we define and freeze the BoM? • Which SW modules can we freeze to reduce at the max the reworking when switching between platforms?