2013 Fifth International Conference on Computational Intelligence, Communication Systems and Networks

A Lightweight Message-based Inter-Component Communication Infrastructure

Tobias Simon, Andr e Puschmann, Shah Nawaz Khan, Andreas Mitschele-Thiel Integrated Communication Systems Group Ilmenau University of Technology 98693 Ilmenau, Germany {tobias.simon,andre.puschmann,shah-nawaz.khan,mitsch}@tu-ilmenau.de
AbstractThis article introduces a lightweight messagebased inter-component communication infrastructure called Signaling and Communication Link (SCL). Specically targeted for inter-process communication in embedded systems, SCL is characterized by three independent building blocks: topology denition, message transport and data serialization. Due to its broker-free, multi-platform, and multi-language messaging approach, SCL speeds up the design process of complex software systems and enables a wide range of applications. We discuss the related work in comparison to our approach, providing a qualitative analysis and specify requirements which are important for designing such a system. The design as well as the implementation and evaluation of SCL are discussed in detail. To illustrate the applicability of our approach in different projects, we discuss two research platforms from the area of mobile communications which already employ SCL as their primary inter-component communication infrastructure. Keywords-modeling; software architecture; component based software

I. I NTRODUCTION Due to advances in System-On-Chip (SOC) architectures in the last decade, more and more embedded systems are able to support General Purpose Operating Systems (GPOS). These operating systems provide a large variety of hardware abstractions such as multitasking, MMU-driven virtual memory management, and peripheral device interfaces. Such an environment allows developers to produce feature-rich rmware using a multitude of programming languages and third-party libraries. However, large software systems are suspect to increasing complexity, which has to be handled using software engineering methods like Component-Based Software Engineering (CBSE) [1]. One important aspect of CBSE in the operating system context is mapping coarse-grained components onto operating system processes. This mapping yields three main benets: First, it supports the usage of different programming languages for implementing components at different levels of abstraction. Second, inter-process communication (IPC) mechanisms allow to separate component interfaces and their implementation. Third, software safety is improved by shielding safety-critical (usually real-time) components from non-safety-critical components using the operating systems memory protection mechanism.
978-0-7695-5042-8/13 $26.00 2013 IEEE DOI 10.1109/CICSYN.2013.18 145

There are several degrees of freedom which complicate the decision what to include in such an inter-component communication infrastructure, and how to design administrative and operative interfaces: Should the infrastructure have implications on the programming paradigm? Does the infrastructure require a central broker or is it working in a decentralized way? Is a static conguration le sufcient or should a dynamic approach be preferred? Should inter-node communication be integrated or should this be delegated to the component implementation? In the embedded software and robotics area, port-based frameworks for inter-component communication like the Lightweight Communications and Marshalling (LCM) [2] and the Robot Operating System (ROS) [3] became more and more popular in the last years. Messaging systems do not force the developer to use a certain paradigm as operationbased frameworks do, i.e. procedural programming in RPC [4] and object-oriented programming in CORBA [5] [6]. Existing messaging-based systems provide all-in-one solutions that create a strong coupling between different aspects like communication topology, transport functionality, and data serialization. We argue however, that these aspects should stay independent to provide as much exibility and control as possible to the developer. To cope with these limitations, we propose a lightweight message-based inter-component communication infrastructure called Signaling and Communication Link (SCL). SCL is easy to use, broker-free, cross-platform, cross-language, and real-time, and utilizes a set of highly specialized open source libraries. The strength of SCL is its limitation to dataformat independent inter-process communication, leaving inprocess and inter-node communication up to the components. This article is organized as follows: We start with related work in order to identify existing approaches in the following section. In Section III we specify a set of requirements for designing a versatile inter-process communication system. Based on these desirable features, we discuss the architecture of SCL in Section IV. Implementation details about the bindings and the supporting infrastructure are given in Section V. We provide a description of two example systems already using SCL in Section VI. Finally, we conclude our work in Section VII.

II. R ELATED W ORK This section reviews existing architectures for inter-component communication specically targeted for embedded or real-time systems. The Robot Operating System (ROS) [3] is not an operating system but a messaging-based middleware. Components exchange messages in a decentralized publish-subscribe fashion using TCP/IP. Publishers and subscribers, which may reside on different network nodes are not aware of each other. As [7] reports, the messaging performance (throughput, delay) is less efcient compared to the ZeroMQ messaging library. As ROS provides built-in data serialization and data type checking, it does not give the developer the freedom to change the underlying mechanism. The Lightweight Communications and Marshalling Library (LCM) [2] also provides data serialization and a publish-subscribe based message transport mechanism for processes running on multiple network nodes. The primary goal of LCM is to simplify the development of low-latency message passing systems, especially for real-time applications like robotics. LCM does not use the operating systems internal IPC facilities like POSIX IPC, but maps everything to the UDP transport, for which it also implements message fragmentation and reassembly. PECOS [8] denes a domain specic composition language called CoCo. The CoCo language denes component hierarchies, and interactions between components through shared variables called ports. The system distinguishes between active, passive or event components, which communicate in a data-ow oriented way. Systems specied in CoCo are mapped directly in the target programming language such as C++/Java as generated class hierarchies, which have to be implemented by the programmer. PECOS does not support cross-language interaction or interaction between separate address spaces in a GPOS. A qualitative comparison between SCL, LCM and ROS is given in Table I.
Feature Publish/Subscribe Request/Reply Inter-node comm. Inter-process comm. In-process comm. Flexible data serialization SCL LCM ROS

2) The system topology should be separated from component code. This allows to write reusable components and it permits component polymorphism. 3) To minimize CPU and memory usage, the transport should be decentralized rather then broker-based. 4) We propose exible data serialization, which allows components to choose a proper serialization format, depending on their individual requirements. 5) The user should not be forced to use a certain inter-process communication paradigm as RPC and CORBA do. 6) It should be easy to extend the infrastructure to support additional programming languages. IV. A RCHITECTURE This section describes the architecture of SCL. We briey illustrate the conceptual idea behind SCL and describe the most important high-level design decisions. A. Design Idea From a software architects point of view, a component communication infrastructure needs to answer three fundamental questions: Which components can communicate? How can they communicate? What do they communicate? We have mapped these questions onto the following three orthogonal logical/functional blocks: Topology Denition: The topology denes which blocks of a component based system can communicate with each other. Message Transport: Message transportation deals with how a message is transported between components. Data Serialization: Data serialization provides a mapping of structured data onto an universal byte stream and thus answers the question, what kind of data is transferred. Most frameworks which address these questions provide a convenient and rich feature-set. This is acceptable for enterprise-grade systems, but fails when it comes to embedded systems. In contrast, SCL follows the KISS principle by addressing these questions independently. A SCL component model is represented as a system-wide topology denition le. This le declares components, gates (communication endpoints), and gate connections for inter-component communication on a symbolic level. It denes names, but it does not dene binary paths to component implementations. Omitting such a convenient feature enables the usage of polymorphic components, i.e. an abstract component having multiple alternative implementations for different purposes. A practical example for such a polymorphic component having two implementations is a Global Positioning System (GPS) data publisher: Such a publisher could be either implemented as an NMEA parser interfacing hardware, or

Supported

Can be extended

Not supported

Table I: Qualitative comparison of component communication frameworks III. R EQUIREMENTS Based on our related work analysis we have identied the following requirements motivating the design of SCL: 1) System conguration and API need to be simple and easy to understand.

146

it could be just a script replaying previously recorded GPS tracks for hardware-in-the-loop testing. Following our philosophy, we did not integrate inter-node communication in SCL because of two main reasons: First, inter-node communication is highly system-dependent and might require highly specialized communication hardware. Furthermore, if a xed topology denition is used, only static network congurations could be supported which would limit the development of mobile networks with changing topologies. Therefore, we leave this function to be solved by either an individual component, or by deploying a special bridging component which connects the system with RPC or CORBA. Message Transport

In addition, it is also possible to extend the system in order to support static type-checking For an example of a system dened with this formalism, see Figure 2. It displays the graphical representation of the topology as well as the formal description of sets C , G and H .

c1 g1 g0 c0 g3 g2

g5

g4

c2

g6 c3

Data Serialization Topology Denition Figure 1: The three dimensions of the component communication infrastructure Figure 1 illustrates the conceptual idea behind SCL. The main advantage of this principle is full exibility as there are no dependencies between these three constituent software dimensions. As a consequence, the decoupling allows to utilize highly specialized open source software libraries for each individual dimension in the implementation. B. Topology Denition SCL employs a topology denition which supports the programmer in transferring inter-component communication set-up from the procedural to the declarative domain. The conguration consists of a nite set of components, C and a nite set of gates, G. A gate is a communication endpoint, which is used by the application. It is also used to interconnect different components by the corresponding message transport back-end. Two subsets of G are dened as ingoing Gin and outgoing Gout gates, with Gin Gout = G. Ingoing gates would, for example in a publish-subscribescenario, be used to subscribe to the outgoing ones. Individual gates are assigned to components using the functions in : C P (Gin ) and out : C P (Gout ). In addition, gates have to satisfy the following namespace condition: (a = b (io (a) io (b) = ))
aC bC

Figure 2: Example architecture dened as: C = {c0 , . . . , c3 }(components), G = {g0 , . . . , g6 } (gates) in = {(c0 , g0 ), (c1 , g3 ), (c1 , g5 ), (c3 , g6 )} (subscribe) out = {(c0 , g2 ), (c1 , g1 ), (c2 , g4 )} (publish) H = {(g0 , g1 ), (g2 , g3 ), (g4 , g5 ), (g4 , g6 )}(connections) C. Message Transport Using the previously dened topology, a message transport infrastructure is required to transfer arbitrary data between multiple components through the gates. The transport subsystem does not interpret the data, but it cares about atomic data exchange, i.e. a message is either received completely or no message is received at all. The sender/receiver side does not care about message fragmentation and buffering, but it should have the ability to control the underlying buffering scheme, if required. SCL provides two basic transport or communication patterns, which must be implemented in the underlying transport infrastructure: Publish-Subscribe or 1:n fan-out is an unidirectional pattern, which connects multiple subscribers to one publisher. Whenever the publisher sends a message, this message is sent towards all connected subscribers. This pattern may also be used for 1:1 communication scenarios in which a single source sends data over to a single sink. Request-Reply is a bidirectional pattern widely applied to client-server based architectures. The client sends a request message to the server, which sends a reply back to the client. The message transport infrastructure has to take care that this pingpong like pattern is enforced. This pattern is useful in scenarios which require acknowledgements, for example command execution with status code. D. Flexible Data Serialization As structured data cannot be handled directly by the underlying transport system, it has to be attened into a

with io := in out. This basically assures that for a component, ingoing and outgoing gates are distinct. The topology of the system is dened using a set of connections between gates. It is dened as: H Gin Gout .

147

Application Code SCL Binding SCL Generator SCL Cache ZeroMQ Binding LibZeroMQ Operating System Generated Protobuf Binding Message Defs LibProtobuf

Topology Cong

Figure 3: Logical top-down view of an SCL-based system using ZeroMQ and Protocol Buffers

one-dimensional byte stream. Available approaches provide a single one-ts-all data serialization mechanism, which has to be used among all software components. We think this is counter productive, as components typically operate on different levels of abstraction. High-level components might want to exchange self-describing, complex data in the JSON format, while low-level components are required to exchange a huge number of simple data sets in a raw binary format efciently. This aspect is completely applicationdependent and thus should not be dictated by the underlying framework. To address this discrepancy formulated in requirement 4, our solution allows multiple independent serialization formats which are completely independent of the underlying topology and transport mechanisms. Each of theses formats needs to provide basic (integer, oat, . . .) and structured (records, arrays, . . .) data types, which are typically available in a programming language. The data transformation is handled by two symmetric interface functions used as follows: binary_data = pack(complex_data), complex_data = unpack(binary_data). It is up to the developer to decide for a serialization library which ts the applications requirements. The developer currently needs to ensure that two connected components understand each others wire format. V. I MPLEMENTATION Our system distinguishes between an administrative and an operational interface. For the system and gate congurations, the administrative interface allows the developer or system integrator to customize the system topology independently of the component code. The operative interface allows message receiving and sending in a natural, socketlike fashion. Figure 3 depicts the logical top-down view on a generic SCL-driven application. The separation between different software dimensions is encoded in different graytones as light gray for topology, gray for transport and dark gray for data serialization. These three independent software parts t very well in the software dimensions shown in Figure 1.

components: - name: sensor gates: - measurements: pub - name: actuator gates: - setpoint: sub - name: controller gates: - sensor: sub - actuator: pub - events: pub - commands: rep - name: user_interface gates: - events: sub - commands: req connections: [ [ [ [ sensor.measurements, actuator.setpoint, controller.events, controller.commands, controller.sensor ] controller.actuator ] user_interface.events ] user_interface.commands ]

Listing 1: Example YAML Topology Cong File

A. Topology Denition The conguration le is described in the YAML format, which is easy to process for both humans and computers, as it uses indentation rather than tags like in XML for structuring the document. YAML uses hash-maps and lists for structuring data. There are two main sections (hash-maps), components and connections which correspond to the sets C and H . The gates G are dened within the components section. The document structure implies that the namespace condition aC bC (a = b (io (a) io (b) = )) is always valid. In the connections section, it can be seen that the individual gate name space is accessed via a dot (.) operator. The denition of H Gin Gout has to be checked by the conguration le parser, in order to guarantee semantic correctness of the document. Listing 1 shows an example system topology dening components, gates and gate connections. The topology denition satises requirement 2 from Section III, as it does not contain transport back-end,

148

serialization back-end or component implementation details. B. Code Generator and Bindings In order to reduce complexity and to mitigate crosslanguage clone code, we have introduced a Python-based code generator for intermediate processing. It addresses requirement 6 from Section III by parsing the system conguration le and generating a more concrete intermediate conguration le, which can easily be processed by the individual programming language bindings. Using the topology conguration le dened in section V-A, the code generator yields the following transport-specic le, which might easily be used by the respective ZeroMQ-supporting binding: The ZeroMQ-relevant attributes are depicted by the zmq_ prex, which basically dene the socket location and some internal socket attributes. If a different message transport infrastructure has to be supported, this generated code, and the binding internal structure will look different. The code generator itself is a Python program, performing the following four steps: 1) parsing the conguration le 2) checking for the semantic correctness (fail-early error handling) 3) transforming the topology description into concrete socket identiers and transport hints 4) serializing and writing the output of the previous step to a YAML-based generated conguration le The code for transforming the parsed topology denition in step 3 into the concrete representation used later by the bindings is shown in Listing 2. Each individual binding (C/C++ and Python) parses the generated code and turns it into language-specic data structures holding already opened socket instances ready for use. The code generator itself consists of only 135 lines of code (LOC), while the Python binding can be reduced to only 39 LOC. The C++ binding counts 263 LOC, which is 6 times more effort compared to the Python code. If we wrote the code generator in C++, approximately 1000 LOC would have been required for the same functionality. Of course, the biggest drawback of this Python-based code generator is the start up time of the Python interpreter. On an ARMv7-based computer module running at 500 MHz and using a Class-10 MicroSD card, roughly two seconds pass until the result is computed. However, as the topology conguration le changes only when the system designer changes the topology, it is possible to speed up this process by caching the generated le. Thus, the binding does not directly invoke the code generator, but instead calls a cache checking shell script. The control ow between the binding, the shell-script and the Python code generator is shown in Figure 4. This script starts up very fast and calculates/checks the MD5 digest of the topology conguration le. In case of a mismatch, the code generator is invoked. We have

# (integrity has to be checked in advance) # conns is a quadruple (comp, gate, comp, gate) # construct socket generating set: sock_gen_set = set() for conn in conns: for i in range(2): if conn[i][2] in [pub, rep]: sock_gen_set |= set([conn[i][0:2]]) sock_gen_list = list(sock_gen_set) # create SCL socket identifiers # and put them into socket map: socket_map = {} for i in range(len(sock_gen_list)): sock_str = ipc:///tmp/scl_%d % (args.base_id + i) socket_map[sock_gen_list[i]] = sock_str # complete socket map for sub & req: for conn in conns: for i in range(2): if conn[i][2] in [sub, req]: socket_map[tuple(conn[i][0:2])] = \ socket_map[tuple(conn[1 - i][0:2])] # build specification for binding: zmq_spec = {} for (cname, gname), gate_type in comp_map.items(): if not cname in zmq_spec: zmq_spec[cname] = [] entry = {gate_name: gname, zmq_socket_type: socket_type_map[gate_type], zmq_socket_path: socket_map[(cname, gname)]} zmq_spec[cname].append(entry)

Listing 2: Code Generator

measured a speed-up by a factor of 20, compared to the non-cached code generator call. Check SCL Cache

yes OK? no Generate SCL Cache no

Bash & Python

OK? yes

Failure

Build SocketMap

Language Binding

Figure 4: SCL Binding Control Flow C. Message Transport Depending on the underlying operating system, different mechanisms for interprocess data exchange and synchronization, like (memory-mapped) les, signals, semaphores,

149

sockets, message queues, (named) pipes, and shared memory are available. All of them have pros and cons, and some of them might not be available on each operating system. Thus, there is a need for having a simple yet powerful interface hiding implementation details and making software portable. Messaging frameworks are one way to provide portability and higher-level features: They allow to implement different communication patterns like publish-subscribe, request-reply and push-pull. Different buffering and ltering strategies have been developed in order to control the systems reliability and timing behavior. By default, SCL uses ZeroMQ, a lightweight broker-free messaging infrastructure to satisfy requirement 3. ZeroMQ implements different communication patterns like requestreply and publish-subscribe. In ZeroMQ, data is exchanged in a message-based form, which means that ZeroMQ takes care of message fragmentation and reassembly, which enables transactional consistence of the transferred data. D. Flexible Data Serialization As the data serialization is implemented by third-party libraries, we do not provide an own implementation for that. We have evaluated the computational complexity for serializing/deserializing data with different libraries in the Python programming language. For each format, a data set containing a tuple of booleans, integer, strings and oating point numbers has been processed. Table II shows the results of the libraries under investigation. 10000 iterations were executed and averaged for packing and unpacking using the different libraries. There is always a trade-off between desired serialization speed, binary data size and the level of abstraction. CPickle, a Python-specic serialization format, produces small binary messages very fast, but it can only be used between Python processes. JSON and XML are slower and larger but interoperable and text-based. Although XML seems to be very efcient in terms of encoding and decoding, it will implicitly put more stress on the underlying transport system due to larger message sizes. Protobuf is fast in C and C++ (although the Python code is surprisingly slow) and it produces the smallest binary output. As stated previously, the decision which format to use is up to the developer. We use Protobuf for most of our systems, which are described in Section VI.
Library cPickle JSON XML Protobuf Packed bytes 38 33 235 25 Encode (ms) 0.0048 0.0080 0.0118 0.0139 Decode (ms) 0.0035 0.0065 0.0661 0.0127

supplying the component identier in form of a string. The binding will then set up connectivity and provide an map of string-identied sockets. The component name resolution is also the place where the polymorphism requested in requirement 2 comes into play: In principle, any program can announce to SCL that it identies itself as a certain topology-dened component. By executing the binding code, the component gets registered with SCL and becomes ready to receive and send messages. SCL supports currently three programming languages: C, C++, and Python. Although the availability of bindings is limited, it is quite easy to create a new one, e.g. for Java as long as the underlying libraries are available. We explain both the C++ and Python binding based on the already used example topology in the following. C++ Binding: The C++ binding consists of a main class, SocketMap, and a helper class, sclGate. SocketMap creates one instance according to the singleton pattern, supplied with the name of the current component using it. It is responsible for opening, binding, accessing and releasing the gate sockets for the component. Gates are accessible using their names, which are dened in the system topology conguration le. The helper class sclGate provides some extra functions for data serialization and deserialization with the help of the protobuf C++ bindings. Listing 3 shows a small example implementation of a component which reads data from a sensor and publishes this data to subscribers in 14 LOC.
#include "sclhelper.hpp" int main(void) { GateFactory &factory = GateFactory::getInstance(); gate = factory.createGate("sensor", "measurements"); while (true) { sensor::sensorMessage message; message.set_data(sensor_hw_read()); gate.sendProto(message); } return 0; }

Listing 3: C++ SCL example using the previously dened component topology Python Binding: Similar to the C++ binding, the Python binding provides a socket map generator function called generate_map, which yields a dictionary comparable to the SocketMap created in the C++ binding. The dictionary generating process is again based on providing the actual components name. The socket is then retrieved using the gate name from the corresponding topology denition le. No further API calls are required - the socket can directly be used for sending/receiving messages, depending on its role. The example in Listing 4 shows an actuator hardware interface receiving set-point updates via SCL, implemented in only 7 LOC.

Table II: Serialization library performance comparison E. Language Bindings Independent of the programming language, each component needs to tell the binding about its own identity by

150

from scl import generate_map from actuator_hardware import update_setpoint socket_map = generate_map("controller") socket = socket_map["actuator"] while True: data = socket.recv() update_setpoint(data)

GPS Sensor (C)

Conguration Daemon (Python)

Autopilot (C)

Mission Arbiter (Python)

Power Management (Python)

Listing 4: Python SCL example using the previously dened component topology VI. C ASE S TUDIES To illustrate the applicability of SCL, we describes two research projects which use the framework for intercomponent communication. We show how SCL reduces system complexity and supports safety in detail. A. ARCADE UAV System The rst application for which SCL was originally designed is called ARCADE1 . ARCADE is capable to autonomously analyse and repair wireless communication networks in disaster scenarios like earthquakes or oods. The computer system on board needs to perform various tasks on different levels of abstraction, ranging from raw sensor and actuator I/O to networking and script-based mission execution. These functions are realized in different software components. While computation-intensive and realtime tasks are implemented in the C programming language, high-layer components with less restrictive requirements are typically implemented in Python. SCL supports this design of such systems by shielding safety-critical from non-critical software but still allowing them to exchange user-dened data in a convenient and predictable way. A recent prototype of this communication platform concept is shown on the photograph in Figure 5.

Blackbox (C++)

UAV Mission (Python)

Communication (Python)

Figure 6: ARCADE Component Interactions

Figure 6 shows the interaction within the ARCADE UAV system without indicating specic gates. Publish-subscribe interactions are indicated by unidirectional and request-reply patterns are indicated by bidirectional arrows, respectively. While real-time and safety critical components are indicated in black, medium critical components are grey and lowpriority components are lled white. An example for a safety-critical, real-time enabled component is the autopilot: this software fuses several sensors like accelerations, angle estimates, GPS data and ultrasonic range measurements and turns them into actuator set-points for stabilizing and controlling the system at a frequency of 300 Hz. Nonsafety-critical software is for example responsible for system conguration, network node localization, or network repair. These components are implemented in the Python programming language, running at low priority. Using ARCADE we were able to test the reliability of SCL extensively in the lab and in the air. Several performance measurements have been conducted to evaluate the performance of the message transport. Evaluations conducted by the ZeroMQ authors show that the system achieves great throughput and scales well with an increasing number of communication peers. We have performed a realtime messaging test to evaluate the level of determinism with and without using a real-time Linux kernel to support the infrastructure. In this test, two components written in Python exchange 20 bytes of payload in a publish-subscribe fashion: Messages are sent at a frequency of 1000 Hz on an ARMv7-based computer module running at 500 MHz. Three scenarios have been evaluated in order to obtain the delay characteristics: In the rst scenario, the system is idle and in the second case additional cpu load has been created using the stress utility. Table III shows a signicant increase of maximum delay. The maximum delay is nearly eight times higher compared to the idle case. In our third experiment we also applied load, but this time both processes were running with real-time priority. Our expectation was that the performance should not be signicantly worse compared to the rst case, which turned out to be true.

Figure 5: UAV System using SCL

1 Airborne Robots for Communication and Autonomy in Disaster Environments

151

Set-Up idle/non-rt load/non-rt load/rt

Min 0.36 0.33 0.39

Median 0.42 0.55 0.45

Mean 0.44 0.71 0.48

Max 1.0 7.7 1.6

Var 1.6e9 2.0e7 1.7e9

Table III: Delay Measurements in ms B. OSPECORR Cognitive Radio Testbed The second application utilizing SCL is OSPECORR2 , an open-source project which aims at providing an experimental platform for research in the eld of Cognitive Radio (CR). CR is a novel radio paradigm which tries to optimize the spectrum usage by exploiting the available communication resources efciently. The software platform developed within the OSPECORR project consists of three main components: a Software Dened Radio (SDR) for providing basic communication capabilities, a Resource Map (RM) for storing environmental information primarily gathered through spectrum sensing as well as a Cognitive Resource Manager (CRM) which is considered to be the brain of the radio [9]. Each of these high-level blocks includes multiple components, which rely on SCL to communicate with each other. Figure 7 depicts the interaction among components within the OSPECORR project. In this example, an application informs the radio link optimization component implemented inside the CRM about its current QoS requirements using a request-reply gate. Based on this and on current environmental information gathered through the signal detection component, the link optimizer recongures the radio parameters of the SDR. Note that the link optimizer component is internally connected to the spectrum mobility block and thus can be informed about changes in the radio environment.
Application
QoS Requirements req rep req

approaches, the architecture of SCL is characterized by three independent functional blocks for topology denition, data serialization and message transport. The software allows to create complex component topologies which are congured in a centralized way but operate distributively. This mitigates bottlenecks and allows to operate embedded real-time critical systems. SCL is not written from scratch but uses highly specialized open source libraries that together are more than just the sum of their parts. Its actively being used in two different research projects. We have also evaluated its performance in terms of transport and serialization delay for an embedded computer module. It has been shown that SCL allows to integrate other programming languages with only a few lines of code by transforming topology denitions into a much simpler formal representation. ACKNOWLEDGMENT This work has been carried out within the International Graduate School on Mobile Communications (MOBICOM), supported by the German Research Foundation (GRK1487) and the Carl Zeiss Foundation. R EFERENCES
[1] G. T. Heineman and W. T. Councill, Eds., Component-based software engineering: putting the pieces together. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001. [2] A. Huang, E. Olson, and D. Moore, LCM: Lightweight communications and marshalling, in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), October 2010. [3] M. Quigley, K. Conley, B. P. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, ROS: an open-source Robot Operating System, in ICRA Workshop on Open Source Software, 2009. [4] B. J. Nelson, Remote procedure call, Ph.D. dissertation, Pittsburgh, PA, USA, 1981, aAI8204168. [5] O. M. Group, The common object request broker: Architecture and specication (corba 2.3.1 specication), Object Management Group, Tech. Rep., Oct. 1999. [6] S. Vinoski, Convenience over correctness, IEEE Internet Computing, vol. 12, no. 4, pp. 8992, Jul. 2008. [7] A. Shakhimardanov, N. Hochgeschwender, M. Reckhaus, and G. K. Kraetzschmar, Analysis of software connectors in robotics, in IROS, 2011, pp. 10301035. [8] M. Winter, T. Genssler, A. Christoph, O. Nierstrasz, S. Ducasse, R. Wuyts, G. Arevalo, P. Mueller, C. Stich, and B. Schoenhage, Components for Embedded Software - The PECOS Approach, in In Proc. International Conference on Compilers, Architecture, and Synthesis for Embedded Systems (CASES), 2002. [9] S. Haykin, Cognitive radio: brain-empowered wireless communications, IEEE Journal on Selected Areas in Communications, vol. 23, no. 2, February 2005.

CRM
Link Optimizer Spectrum mobility

SDR
Radio Reconfiguration Signal Detector rep

sub

Resource Map
pub sub Database

Figure 7: Component interaction within the OSPECORR project VII. C ONCLUSIONS In this article, we have introduced a novel message-based component communication infrastructure targeted for interprocess communication in embedded systems. Unlike other
2 Open

Software Platform for Experimental Cognitive Radio Research

152