1 / 54

Real-time Operating System (SafeSOS) for Multicore Wireless Sensor Nodes (WSN)

International France-China Workshop NISCT’13: New and smart Information Communication Science and Technology to Support Sustainable Development. Clermont-Ferrand, France. Real-time Operating System (SafeSOS) for Multicore Wireless Sensor Nodes (WSN).

milla
Download Presentation

Real-time Operating System (SafeSOS) for Multicore Wireless Sensor Nodes (WSN)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Real-time Operating System (SafeSOS) for Multicore Wireless Sensor Nodes (WSN) Xing Liu, Kun Mean HOU, ChristopheDE VAULX LIMOS, University Blaise Pascal

  2. OUTLINE • Background and Motivation • Scheduler of SafeSOS • Dynamic Memory Management in SafeSOS • Middleware in SafeSOS • Inter-Communication Mechanism • Reliability Mechanism • Conclusion

  3. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Background and Motivation

  4. Background and Motivation • Real-time is required in many WSN applications: • industrial engineering control, • medical care (heart pacemakers monitoring), • military battlefield surveillance, etc. • Current WSN OSs (Contiki, TinyOS, SOS, etc.) cannot support real-time. Some OSs (like UCOS) are real-time, but resource consumption is too high, too suitable for WSN platform. • Motivation 1: Design a WSN OS that can support real-time, meanwhile, with low memory resources consumption.

  5. Background and Motivation • Why multicore (Not single core) WSN node? • More intelligent (cooperation among different cores, task split and distribution, memory resource sharing). • More robust. • Lower Energy Consumption. • Motivation 2: Different microcontrollers integrated on one board, so: How can the new OS safeSOS be able to abstract the diverse Microcontrollers’ hardware details, thus to simplify the software development process?

  6. General Structure of SafeSOS Motivation 1: Real-time OS & Low memory resource consumption Hybrid scheduler Dynamic Memory Management Motivation 2: Abstract the diverse hardware details SafeSOS middleware Inter-Communication Mechanism OS Reliability Mechanism

  7. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Hybrid scheduler (event-driven + multithreading) to support Real-time

  8. Execution Model of Current WSN OSs

  9. Why Hybrid Scheduler in SafeSOS? • To reduce the memory resource consumption, event-driven scheduling model is used. But event-driven OS doesn’t support preemption, and thus cannot achieve the real-time reaction. • To support the real-time reaction, the multithreading scheduling also needs to be implemented. But multithreading OSs are high consumed in memory resources. • Thus: both the event-driven and multithreading schedulers are carried out in SafeSOS. Meanwhile, in order to reduce the memory resource consumption, some mechanisms should be taken. How to achieve these?

  10. Hybrid Scheduling Model • In SafeSOS, two schedulers are implemented in pararrel: • Event-driven scheduler & multithreading scheduler. • Events are classified into three types in terms of the emergence: • common events, soft real-time (SRT) events, Hard real-time (HRT) ones. • Since hard real-time (HRT) events need to be reacted immediately. Thus, • they are dispatched by the multithreading scheduler. • and for common/SRT events, they are dispatched by event-driven scheduler.

  11. Hybrid Scheduling Model • Two schedulers can switch to each other. But at any time, only one kind of scheduler is active. • If only common /SRT events exist in the system, the OS runs in the pure event-driven model, in this case, the system memory consumption is low. • And this is safeSOS’s default scheduling model.

  12. Hybrid Scheduling Model • If one or more HRT events are triggered, the execution of the current • event-driven scheduler will be suspended immediately, and then the OS will • switch into the multithreading model. • In this model, one thread will be created for each HRT event, all the threads run concurrently to execute the HRT handlers.

  13. Hybrid Scheduling Model • The OS will switch from the multithreading model back to the event-driven model again when: • all the threads are suspended, or • all the threads run to completion. • By means of this hybrid scheduler, the real-time reaction to the time-critical HRT events can be achieved. • But is the memory resource consumption of this hybrid scheduler high or not?

  14. Memory Resources Consumption Analysis • 1). Since HRT events are only generated in some typical cases, safeSOS runs in event-driven model most the times, and the memory resource consumption is low in this case. • 2). Even when the HRT events are generated and the OS runs in the multithreading model, • the memory resource consumption is still not high because the number of the HRT events is small (commonly, less than 3). thus, less threads are created.

  15. Memory Resources Consumption Analysis • 3). In order to reduce the memory resource consumption further, the dynamic memory allocation is used. Thus: • The thread stacks are allocated dynamically. Only when a thread is created, the stack is allocated. And after a thread handler runs to completion, all the memory resources related to this thread will be freed. • Due to the above reasons, the resource consumption of safeSOS is much lower than the pure multithreading OS (mantisOS, etc.).

  16. Event-driven Scheduling Algorithm • As the event dispatcher may not be able to handle all the events as quickly as they arrive, an event queue is needed to buffer the upcoming events. • Three kinds of event queues (EQ) are defined: • A). common EQ (CEQ): buffer the common events / FIFO algorithm • B). SRT EQ (SEQ): buffer the SRT events / EDF(Earliest deadline first) algorithm • C). postponed EQ (PEQ): buffer the common or SRT events that cannot be • processed successfully after it is dispatched. • Queue Scheduling Priority: PRI (PEQ) > PRI (SEQ) > PRI (CEQ)

  17. Multithreading Scheduling Algorithm • Since few HRT events that will be generated simultaneously in SafeSOS, thus the simple, easy-to-implemented, and starvation-free RR (Round-Robin) algorithmis used for the thread dispatching. • All the threads have the same priorities.

  18. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Dynamic Memory Management in SafeSOS

  19. Memory Allocation Mechanism (1)--- Statically reserved, dynamically fixed-size block allocated • Limitations: • 1). The size of some objects cannot be pre-known, e.g., the size of the • received packet. In this case, we cannot reserve a block area for it. • 2). If the reserved capacity for a given block area is not big enough, the • overflow problem will occur. • HOW to solve these problems?

  20. Memory Allocation Mechanism (1) A given area in the heap is kept as “Flexible Area”. • For the “flexible area”, it will be used in two cases: • 1). For the allocation of the objects of which the size is not pre-known. • 2). In case that the pre-reserved capacity for a given block area is not big enough, the allocation can be continued from this area. Thus, overflow problem can be avoided.

  21. Memory Allocation Mechanism (1) • Drawbacks of this memory allocation mechanism: • 1). Static reserved memory space cannot be shared. • 2). Memory fragment problem can exist in the “flexible area”.

  22. Memory Allocation Mechanism (2)--- Dynamic allocation + fragment assembling • No pre-reservation for the memory resources, use dynamic allocation. • How to solve the memory fragment problem? • Use indirective memory access mechanism. Fragments can be assembled by compacting the heap, and after compaction, update the reference to keep the access to the allocated objects still be available. (E.g., allocate a 60-bytes object from (a). )

  23. Memory Allocation Mechanism (2)--- Dynamic allocation + fragment assembling • Advantage: • -> No need to reserve the memory resource. • -> Memory resources can be used efficiently as the fragments can be collected. • Drawback: • Allocated objects should be accessed indirectly, e.g., use “(*p)->” instead of “p->”.

  24. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. SafeOS Middleware to Simply the Application Development on Multicore Node.

  25. SafeSOS Middleware:-- Simply the application development on multicore node • Middleware features: • -> uncouples the applications from the systems, • -> implements a set of system services in the system space • -> provides a set of unified interfaces for the application development.

  26. SafeSOS Middleware:-- Simply the application development on multicore node • Advantages: • 1). The application development process becomes simple and the development time can be shorten. Because: • for the users who develop the applications, they can only focus on the application space, without the necessity of reading the manuals of the different microcontrollers, and also without the necessity of mastering the development tools such as AVR studio, AVR emulator, etc.

  27. SafeSOS Middleware:-- Simply the application development on multicore node • Advantages: • 2). The application reprogramming performance improve greatly. • Without middleware, if the node’s application functionality needs to be changed, the whole software binary needs to be updated. (its size can be more than 100 KB.) This can cause the WSN node’s energy to be exhausted. • After the middleware is implemented, only the application image is needed to be updated. (the size is commonly as small as 100-300 bytes.)

  28. SafeSOS Middleware:-- Simply the application development on multicore node • Advantages: • 3). Due to the unified programming interfaces provided by middleware, the applications on the multicore node is hardware independent, thus: • An application can be moved from one core to another without adaption.

  29. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. SafeSOS Inter-Communication Mechanism To simply the communication among different cores.

  30. SafeSOS Inter-Communication Mechanism • Features of SafeSOS Inter-Communication Mechanism: • The communication among all the microcontrollers are done • 1) through the “Channel & Pipe”. • 2) through a unified service interface “send(channel, pipe)”. • Why in this way?

  31. SafeSOS Inter-Communication Mechanism • By means of SafeSOS Inter-Communication Mechanism: • When developing the software, • the communication among the different cores on the multicore node seems to be as the communication among the different software tasks on a single-core node.

  32. SafeSOS Inter-Communication Mechanism • Example: When AVR microcontroller distributes a child task to the ARM microcontroller. • If the memory resources on ARM board is not enough, then change the “channel & pipe” to distribute this task to the Raspberry microcontroller.

  33. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. SafeSOS Reliability Mechanism.

  34. SafeSOS Reliability:--Finite State Machine Architecture to Improve System Reliability • Use Finite State Machine Architecture to develop different modules. • Before state execution, back up the global data related to this state. • After each state executed, check the • results: • -> If result correct, move to next state. • -> If not correct, recovery the modified data and re-execute this state. • ….

  35. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. New OS Debug Method

  36. Drawbacks of current Debug Methods 1) Print debug information by Printf • cannot be used on sensor nodes as there are commonly no screens. • execution overhead is too high for resource-constrained sensor platforms. 2) Sending debug information out from the Serial ports the sending speed of the debug data from the serial port is much slower than the execution speed of the instruction codes, thus the memory overflow problem will occur. 3) Breakpoint setting not effective as many interruptions and preemptions happened concurrently inside the system, once a breakpoint is set, the execution of the system will halt, thus it is difficult to know how the system runs in detail.

  37. Requirements to the OS Debug Method A good debug method should have the following features: 1). has a low execution overhead, thus will not influence the sensor node’s regular execution process. 2). can process the debug data in a high speed.

  38. Multicore Supported Debug Method for SafeSOS • In this system, the sensor board is divided into two parts: • the working board and the debug board. • Two boards are connected through the GPIO ports. • Every time the iLive node takes some actions, it only send some raw • debug code to the GPIO ports, and then let the left debug work be • undertaken by the Raspberry board. • By this way: the debug overhead on iLive node decreases, because • the main debug work is undertaken by the debug board.

  39. Multicore Supported Debug Method for SafeSOS 0xAC, 0x20, 0x1A “Malloc 0x201A” GPIO 0x6A “Thread_dispatcher” GPIO 0xC2, 0x21, 0x68 “Post_event 0x2168” GPIO

  40. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Conclusion and Ongoing Work

  41. SafeSOS comparisons. • Compared with pure event-driven OS (TinyOS, Contiki, etc.): • Pure event-driven OS cannot support real-time. • But this can be achieved in SafeSOS . • Compared with the pure multithreading OS (mantisOS): • Memory resource consumption of safeSOS is much less. Because SafeSOS: • mostly, runs in the event-driven model. • even in the multithreading model, resource consumption is not high: • A). Thread number in safeSOS is much less than pure multithreading OS. • B). Use dynamic allocation for the thread stack. The stacks are allocated only when the HRT events are generated. • (In pure multithreading OS, the stacks are allocated in the startup initialization process.)

  42. SafeSOS Kernel Size: • SafeSOS kernel code size: 3088 bytes.

  43. Ongoing Work: • Application Code Generated by GUI. • Task split and distribution. • Fault injection from the middleware. • Roll-back Recovery to improve the fault tolerance. • etc.

  44. International France-China Workshop NISCT’13: New and smart Information Communication Science and Technologyto Support Sustainable Development. Clermont-Ferrand, France. Thank you for your attention. Any question? Supported emails: liu@isima.fr, kun-mean.hou@isima.fr

  45. How to Switch the scheduler Model • In order to make the switch process be more efficient and easy-to-managed, • the event-driven scheduler in safeSOS is also implemented as a thread "main_thread", • Thus, • when the thread switch function “getNextThread” is called, if the “&main_thread” is returned, the OS switches back from multithreading model to event-driven model.

  46. Development Process Problems to solve: After the applications are separated from the systems, four problems need to be solved: 1). How to link an application customer function to a system service function? 2). How to pass the function parameters from the application customer functions to the system service function? How to pass the return value from the system service functions to the application customer functions?

  47. Development Process Problems to solve: 3). Callback problem: How to enable the function callback from the system space to the application space? 4). Multitasking applications problems: How to support the multiple applications in the only one application image?

  48. Applications Supported by Middleware Image size: 168 bytes.

  49. Comparison with Contiki • Contiki also implements a hybrid scheduler, but • the multithreading model in Contiki is implemented as an optional library upon the event-driven model. • Thus, the preemption can only achieved inside a process, and the real-time reaction cannot be well supported. e.g., if process A is running and a HRT event is triggered which needs to be processed by the thread C-2. In Contiki, this HRT event cannot be responded immediately as process C cannot preempt the process A. • But in HEROS, the event-driven scheduler and the multithreading scheduler are implemented in parallel, thus the real-time can be achieved by the scheduling model switch.

More Related