Conference:International Conference on Distributed Computing in Sensor Systems and Workshops


  • Alexandru Caracas [a]
  • Alexander Bernauer [b]
  • Thorsten Kramp [a]

  • a. IBM Research - Z¨urich
  • b. ETH Z¨urich, Institute for Pervasive Computing


  • 無線感知網路越來越常被用在業務流程改善上,只是一般來說都是以手繪的方式來描繪業務流程,然而手繪流程不僅曠日費時,也容易造成模型與實際執行之間的落差,因此造成大家都不是很願意描繪與WSN有關的業務流程。本篇文章便專注於縮小流程模型轉換成應用軟體的距離。本篇文章提出的方法是先由軟體開發人員發展出一些基礎的功能模組,之後再讓業務分析人員可以透過這些功能模組,迅速且有效率地去描繪業務流程,並且透過本研究所發展的編譯器(Compiler)及模擬器(Simulator),讓業務分析人員可以很方便地針對其所描繪的業務流程進行測試與除錯。另外,本篇文章也針對其所提出的方案進行效能評估,評估結果顯示由編譯器所產生的程式碼,可以在資源有限的感知器上運行且僅需要多耗費1%的電力。同時採用本篇文章的方法平均可以節省RAM記憶體及Flash記憶體超過10%及44%的記憶體空間。



  • 本篇文章主要在談及如何將業務流程模型自動轉成程式碼並佈建在Sensor節點上,使無線感知與反應網路(WSN)可以根據設計的流程執行。
  • 為了達到上述之情境,本篇文章擴充了Business Process的Editor,並加入Compiler與Simulator來協助Business Process Analyst規劃、開發與測試WSN的應用程式。



  • 本篇文章的重點是以MDA的概念來發展WSN Application,所以強調的是如何將Business Process轉換成Binary Code,並且可以配置到Sensor上執行。
    • 而我比較想要知道是否有可能發展出與WSN-based的流程引擎,依據BPMN的規劃透過流程引擎掌握WSN的狀況、狀態的推論以及控制WSN的處理邏輯。
    • 找找看有沒有WSN之流程引擎的資料?
      • 流程引擎的架構?
      • 如何掌握WSN中的狀態?



  • We aim at closing this gap (deviations between the model and the implementation) by automatically generating applications from the model of the process instead.
  • Business processes are designed and modeled by business analysts who are domain experts in their field but do not necessarily have a background in IT. Thus, the actual implementation of a business process is typically performed by software developers.
  • Software developers provide building blocks that are used by business analysts to model business processes and hereby effectively control their execution on an abstract level.
  • Furthermore, the model editor integrates a compiler and a simulator so that the business analysts can test and debug the modeled processes on the same level of abstraction.
  • Our approach provides a unified view over all involved systems, supports simulation and debugging of business processes directly in the model view, and generates efficient code.


  • Wireless sensor networks are increasingly being used to improve business processes. The behavior of such a process is usually captured in models while its implementation is typically created manually.
  • Besides being expensive, this approach entails deviations between the model and the implementation of a business process, thus rendering it less effective.
  • This prevalent approach poses two major problems.
    • Firstly, the implementation usually deviates from the intentions and expectations of the business analysts because cross-domain communication is prone to misunderstandings. This deviation typically renders the respective business process less effective the larger it becomes. In order to avoid this, technology implementations should follow the business process and not vice versa [4].
    • Secondly, changing the model of a business process necessitates the adaption or even recreation of parts of the implementation. As this is expensive and time consuming [5], business processes tend to adapt slowly to changes of requirements or business facts.
  • In this paper, we propose to use the standardized Business Process Model and Notation (BPMN) [6] as the interface language between business analysts and software developers and to apply code generation to turn BPMN models into executable code.
  • In summary, none of the existing solutions bridges the gap between the model description provided by business analysts and the corresponding implementation of a business processes for the resource-constrained sensor networks we are targeting.



  • In our approach, instead of being just a documentation blueprint, a BPMN model actually defines the execution of the respective business process and can be simulated and debugged directly in the model editor.
  • Additionally, BPMN supports the integration of multiple involved distributed systems into a single top-level model, thus covering the demands of business processes which use WSN.
  • For the resource-constrained sensor nodes which we want to support, a model interpreter like a BPEL engine is not a viable option. Instead, we use a compiler to generate efficient code which executes directly on the targeted sensor node platform.
  • To enable better integration into the environment, reduce power consumption, and decrease production and deployments costs [7], we focus on the lower-end spectrum of embedded devices such as 8-bit MCUs with 128 kB of non-volatile memory, and 8 kB of volatile memory. To this end, our compiler generates efficient code which runs on such resource-constrained sensor nodes.



圖1. Classic Business Process Model for Parcel.
圖1. Classic Business Process Model for Parcel.


  • Models for WSN applications should support the distributed, heterogeneous and reactive characteristics of this domain.
  • For energy efficiency considerations, models should also allow control over the protocols used for communication.
  • Since a WSN is usually connected with other systems, the modeling language should support such integration.
    • The syntax and semantics of BPMN need neither be extended nor restricted to fulfill these requirements.
    • The reactive nature of WSN applications is captured by BPMN events and the processing of events by BPMN sequence flows.
    • Communication only takes place via messages between pools and pools can have multiple instances.
    • Different transmission modes such as broadcast and unicast, and different communication protocols such as IEEE 802.15.4 and TCP/IP can be chosen for each communication flow separately.
      • To this end, base stations could send emails to an operator who sends back commands via HTTP requests, for instance.
      • The communication between the operator and the WSN is simply represented with properly annotated communication flows in a BPMN model and
      • the code generation takes care that the communication routines which are provided by the software developers are invoked.
    • Different entities of a distributed system such as various kinds of WSN nodes can be modelled with different pools.
      • In BPMN, each pool contains a task which uses sub-tasks. Such a sub-task can be refined by an additional model or can be a basic task which maps to an API function of the target platform.
      • The set of all basic tasks is part of the platform API which the software developers implement once and reuse for all business processes which involve the given target platform.
    • Due to the recursive nature of BPMN models, our approach allows to choose the border between modeling and programming at arbitrary levels of abstraction.
      • The building blocks for the models which are created by the business analysts can contain both basic tasks and tasks which are modeled.
      • As a rule of thumb, general sequence flows of processes should be modeled while algorithms and device drivers should be programmed.

圖2. Model of Parcel
圖2. Model of Parcel

Code Generation

The core of our approach is a compiler which translates models into executables.
  • The static mode because it provides a one-to-one mapping between tasks and its enclosed data objects.
  • The dynamic mode there are parallel tasks which are invoked more than once at the same time.
  • The compiler has to translate the sequential and parallel computation semantics of a BPMN model into equivalent event-based code.
    • Event Handler
      • Event-based platforms typically use a single dispatcher which constantly takes the oldest event out of an event queue and calls the corresponding event handler.
      • Event handlers may not block when waiting for something. Instead they only trigger a corresponding split phase operation and delegate the remaining processing to a callback which is a second handler that is registered at the run-time environment.
    • Sequence Flow
      • By following this pattern the compiler maps each sequence flow to a chain of event handlers which are causally related to each other by the respective events.
      • As long as a split-phase operation has not yet completed, the dispatcher calls handlers which correspond to other sequence flows, thus processing multiple sequence flows virtually in parallel.
        • We call a basic task with a split-phase interface a critical task.
        • All tasks which enclose critical tasks are also called critical.
      • If a sequence flow reaches a task, the generated code simply calls the function corresponding to the start event of the invoked task. Furthermore, for every possible continuation - i.e. catch events at the border of the task or outgoing sequence flows in the case of a critical task - the pointers of the corresponding functions are saved in extra continuation variables. These variables are managed the same way as data item variables are.
      • If a sequence flow reaches a throw event, the generated code simply consults the corresponding continuation variable and calls the continuation.
      • If a sequence flow reaches an end event, the generated code simply returns from the function in the case of a non-critical task.
      • Otherwise it consults the continuation variable for the outgoing sequence flow and calls the continuation.
      • Basic critical tasks are manually implemented along these lines, so that the computation can continue after completion of a split-phase operation.
    • Terminate Event
      • Terminate events require more effort as the BPMN semantics require that all active sequence flows of the enclosing task are canceled.
      • For every critical task a terminate function is generated which recursively invokes the terminate functions of the enclosed subtasks.
    • Gatway
      • The transformation of if gateways simply generates a corresponding if structure. Concerning parallel gateways, the translation exploits the fact that in a sound model there is always a one-to-one mapping between fork and join gateways.
      • Note that for this to be true one has to consider an implicit join gateway in front of all end events. Furthermore, every throw event is implicitly followed by an end event. These model transformations are performed automatically and do not alter the model semantics.
      • Each pair of join and fork gateways share a common counter variable for the number of active sequence flows between the fork and the join.
        • So, the translation of the fork gateway is code which first increases the counter by the number of outgoing sequence flows and then calls the respective functions of the outgoing flows in turn.
        • Accordingly, a join gateway results in code which decrements the counter by one. If and only if the counter equals zero the function that covers the single outgoing sequence flow is called.

圖3. Model for a Blink application which toggles an LED every 500 ms.
圖3. Model for a Blink application which toggles an LED every 500 ms.

圖4.  Sample generated code in static mode from Blink model
圖4. Sample generated code in static mode from Blink model

Tools Development

The realization of our approach requires a set of integrated tools: an editor, a compiler and a simulator.
  • The compiler transforms a model into an executable in a three-phase translation.
    • In the first phase, the model is checked for consistency and soundness.
      • There are several constraints on the model which should be checked by the compiler in phase one.For example, unconnected flows, unused data or undefined tasks are not allowed, and all thrown events must also be caught.
    • Next, the compiler performs a pattern-based platform neutral translation as described in SectionV.
    • The third phase then is platform specific and translates the intermediate representation from phase two into suitable code for the target platform.
      • For each entity, the compiler generates one binary using a back-end for the respective target platform. These binaries can be installed on real hardware or executed in the simulator.

Compilation and simulation are triggered by the business analysts who use the editor as their primary tool.

圖5. Web-based model editor for BPMN modeling, simulation and debugging of wireless sensor networks
圖5. Web-based model editor for BPMN modeling, simulation and debugging of wireless sensor networks


  • In summary, we enable business analysts to control, simulate, and debug the execution of their business processes on an abstract level.
  • Our evaluation results show that the generated code can be executed on resource-constrained sensor nodes consuming only 1% more energy than the hand-written equivalents. However, the benefits of our approach come at the price of 10% more RAM and 44% more flash space consumption on average.

  • Tools
    • Model editor which is a web-based application based on Oryx [28], a BPMN 2.0 editor distributed under the MIT license.
    • We extended the functionality of the Oryx editor to include plugins that integrate the compiler and the simulator into the editor.
    • The communication interface between the web browser, our compiler toolchain, and the sensor network simulation framework uses a RESTful API with data encapsulated in JSON messages.
    • We use the Mote Runner[26] platform as WSN development environment.
    • The compiler plugin calls the compiler tool which generates C# source code for the Mote Runner platform.
    • The simulator plugin creates the corresponding sensor network configuration for the simulator according to the pools and their respective cardinality.







  • BPMN[6] is additionally suitable for transformation to execution languages such as the Business Process Execution Language (BPEL)[19] where a BPEL engine executes models while communicating with the environment via Web Services.


  • Rhapsody[9] is an industry solution for UML-driven development and automatic code generation for embedded systems.
  • Recent work in this area (Modeling and Executing for WSN) even addresses WSN [10] using Sun SPOTs [11] with a 32-bit ARM core.
  • Other proposed solutions for graphical programming and model-based development of sensor network applications
    • [12],[13] are based on the LabVIEW[14] and Simulink[15] proprietary standards.
    • Viptos [16], Flow [17], and Srijan [18] are modeling environments for wireless sensor networks with custom graphical notations based on data flows.
  • Existing approaches which integrate sensor networks into business processes focus on this approach [20], [21], [22].


  1. Spieß, P. et al., “Integrating Sensor Networks with Business Processes,” in Work. on Real-World Sensor Networks at ACM MobiSys, 2006.
  2. S. Sch¨afer, “Secure Trade Lane: A Sensor Network Solution for More Predictable and More Secure Container Shipments,” in Comp. to the 21st Symp. on Object-Oriented Programming Systems, Languages, and Applications, 2006, pp. 839–845.
  3. S. Krishnamurthy and L. Lange, “Distributed Interactions with Wireless Sensors Using TinySIP for Hospital Automation,” in Proc. of the 6th Conf. on Pervasive Computing and Communications, 2008, pp. 269–275.
  4. M. zur Muehlen and D. T. Ho, “Service Process Innovation: A Case Study of BPMN in Practice,” in Proc. of the 41st Conf. on System Sciences, 2008, pp. 372–372.
  5. F. P. Brooks, Jr., The Mythical Man-Month. Addison-Wesley, 1995.
  6. OMG, “Business Process Model and Notation,” www.bpmn.org.
  7. OMG, “Unified Modeling Language,” www.uml.org.
  8. IBM, “Rational Rhapsody,” www.ibm.com/software/awdtools/rhapsody.
  9. G. Fuchs and R. German, “UML2 Activity Diagram Based Programming of Wireless Sensor Networks,” in Proc. of the ICSE Work. on Software Engineering for Sensor Network Applications, 2010, pp. 8–13.
  10. Sun Microsystems, Inc., “Sun SPOT World,” www.sunspotworld.com.
  11. M. Ghercioiu, “A Graphical Programming Approach to Wireless Sensor Network Nodes,” in Proc. of the Sensors for Industry Conf., 2005.
  12. M. M. R. Mozumdar et al., “A Framework for Modeling, Simulation and Automatic Code Generation of Sensor Network Application,” in Proc. of the 5th Conf. on Sensor, Mesh, and Ad Hoc Communications and Networks, 2008.
  13. National Instruments, “LabVIEW,” www.ni.com/labview.
  14. Mathworks, “Simulink,” www.mathworks.com/products/simulink.
  15. Cheong, E. et al., “Viptos: A Graphical Development and Simulation Environment for TinyOS-based Wireless Sensor Networks,” University of California at Berkeley, Tech. Rep. UCB/EECS-2006-15, 2006.
  16. T. Naumowicz et al., “Prototyping a Software Factory for Wireless Sensor Networks,” in Proc. of the 7th Conf. on Embedded Networked Sensor Systems, 2009, pp. 369–370.
  17. A. Pathak et al., “Srijan: A Graphical Toolkit for Sensor Network Macroprogramming,” in Proc. of the the 7th Joint Meeting of the European Software Engineering Conf. and Symp. on the Foundations of Software Engineering, 2009, pp. 301–302.
  18. OASIS Technical Committee, “Web Services Business Process Execution Language Version 2.0.” www.oasis-open.org/committees/wsbpel.
  19. N. Glombitza et al., “Using Graphical Process Modeling for Realizing SOA Programming Paradigms in Sensor Networks,” in Proc. of the 6th Conf. on Wireless On-Demand Network Systems and Services, 2009, pp. 57–64.
  20. “Integrating Wireless Sensor Networks into Web Service-based Business Processes,” in Proc. of the 4th Work. on Middleware Tools, Services and Run-Time Support for Sensor Networks, 2009, pp. 25–30.
  21. Spieß, P. et al., “SOA-Based Integration of the Internet of Things in Enterprise Services,” in Proc. of the Conf. on Web Services, 2009, pp. 968–975.
  22. C. Favre and H. V¨olzer, “Symbolic execution of acyclic workflow graphs,” in Proc. of the 8th Int. Conf. on Business Process Management, 2010, pp. 260–275.
  23. A. Dunkels et al., “Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors,” in Proc. of the 29th Conf. on Local Computer Networks, 2004, pp. 455–462.
  24. J. Hill et al., “System Architecture Directions for Networked Sensors,” SIGPLAN Notices, vol. 35, no. 11, pp. 93–104, 2000.
  25. A. Caracas¸ et al., “Mote Runner: A Multi-language Virtual Machine for Small Embedded Devices,” in Proc. of the 3rd Conf. on Sensor Technologies and Applications, 2009, pp. 117–125.
  26. L. Motolla and G. Picco, “Programming Wireless Sensor Networks: Fundamental Concepts and State of the Art,” ACM Computing Surveys, to appear.
  27. Oryx, “Oryx Editor,” bpt.hpi.uni-potsdam.de/Oryx.
  28. L.S. Bai et al., “Archetype-based design: Sensor network programming for application experts, not just programming experts,” in Proc. of the International Conference on Information Processing in Sensor Networks, 2009, pp. 85–96.
  29. Memsic, “IRIS Wireless Measurement System,” www.memsic.com.