Progress and Integration. During the second year of the project, an earlier version of the tool called XXX has been ported to Java. XXX provides similar features to jSAM but is implemented in OCaML. This porting is the necessary first step towards the integration of the tool into SDE.
Progress and Integration. The Xxxxx Daemon Wrapper has been developed during the second year of the project. The Xxxxx Daemon Wrapper facilitates the interaction of Xxxxx with other tools reg- istered to the SDE by exposing those features via the function executeMaudeCommand (command,commandType,resultType), which takes care of initialization tasks, executes the Xxxxx command command, and returns part of the Xxxxx output as specified by resultType. A detailed description of Xxxxx and its commands is available in the Xxxxx manual at http: //xxxxx.xx.xxxx.xxx/xxxxx0-xxxxxx.
Progress and Integration. The BIP compiler and the core BIP tools have been recently rewritten. The BIP compiler is organized in Java packages in a modular way, allowing the dynamic invocation of model-to-model transformers and backends. We currently support C++ code generation, which can be executed, simulated or ex- plored using the centralized single-thread engine. We plan to integrate the latest version of the core BIP tools, that is, the compiler and its dedicated execution engine. The rewrite of the BIP compiler and the core BIP tools naturally impacts the additional analysis tools that rely on the BIP compiler, such as the D-Finder compositional verification tool. Updating these tools is work in progress, carried out to reflect the project tool integration requirements.
Progress and Integration. Work on GMC in the second project year included extensions for the C++ language features, and sup- port for custom listeners. Registered custom listeners get notified during the state space exploration as soon as a potentially interesting action, such as a method call, an instruction executed, or backtracking occurs. This extension distinguishes GMC for the purpose of the ASCENS project, where it can check ensemble related properties. Multiple bugfixes and code optimizations have also been implemented. As the development of GMC progresses, the integrated development platform will allow using GMC on ARGoS controllers, verifying properties either encoded as assertions in the code, or specified externally.
Progress and Integration. Eight versions of ARGoS have been released in the course of the last years, with both bug fixes and new features. The webpage of ARGoS underwent extensive restyling, with the aim of simplifying its navigation. Forums have been added to the website to provide support to beginner users and collect tickets and feature requests. Besides this, an article about ARGoS was published in the Linux4You magazine.1 A journal paper about ARGoS design has been submitted to the Swarm Intelligence journal and is currently under review. Because ARGoS is written in C++, integrating ARGoS with the SDE requires wrapping the AR- GoS interfaces in Java. To achieve this result, two approaches are viable: (i) manually wrapping the relevant functions, or (ii) use automated tools such as SWIG.2 Manually wrapping the interface would potentially allow us to optimize the final result better than through an automated method. However, the process of manually wrapping is likely to be language- specific, while automated tools like SWIG allow to create wrappers to different languages easily. We are considering the options of interfacing ARGoS not only with the SDE, but also directly to SCEL-based tools such as SCELua. Thus, it will be necessary to produce at least two language wrap- pings for the ARGoS interface — Java, for the SDE, and Lua, for SCEL-based tools. In addition, we are also considering a Python binding, which could prove useful to promote ARGoS as an educational tool for students and robotics enthusiasts. For these reasons, we finally choose to pursue the SWIG approach. In practice, this approach consists in annotating the ARGoS interfaces with C++ comments written in a special syntax defined by the SWIG interpreter. Once annotated, the code is ready to be wrapped in any language supported by SWIG. SWIG supports all major languages, including Java, Python, Xxx, Xxxx, and even PHP and Perl. Generating the wrapper code is an automatic process performed by the command swig. For a simple example of this approach, we suggest the reader to refer to this webpage: xxxx://xxx. xxxx.xxx/xxxxxxxx.xxxx. 1xxxx://xxx.xxxxxxxxx.xxx/2012/05/open-source-robotics-multi-robot-simulators 2xxxx://xxx.xxxx.xxx Currently, we are in the process of annotating the ARGoS interfaces. A first version of the anno- tations is almost finished. Once finished, the resulting wrappers will require extensive testing before reaching the next phase. The next phase consists in actually integrating the Java wrappe...
Progress and Integration. The jDEECo runtime framework has been wholly developed during the second year of the project, following the design of the DEECo component model.
Progress and Integration. The first version of jRESP has been completely developed during the second year of the ASCENS project. The current version of jRESP is not yet integrated with SDE. The integration will take the form of a high-level programming language, which will enrich SCEL with standard programming primitives and thus simplify the development of SCEL programs.
Progress and Integration. During the last year, the specification of the science cloud platform has been finalized and is presented in [vRA+12]. The first implementation aimed at creating a baseline adaptivity functionality in the form of a failover system has been created. This system is based on OSGi and is thus able to dynamically install, start, stop, and uninstall applications in the form of bundles. Moreover, the system itself is based on OSGi bundle class loading and the OSGi service-oriented component infrastructure and can thus be easily used for testing different implementations of adaptivity and self-awareness. Since the science cloud platform is still under development, it is not yet integrated into the SDE. It is, however, envisioned that an SDE facade can be provided for both basic lifecycle functionality (starting, stopping) as well as runtime monitoring and control.
Progress and Integration. The SPL framework has been entirely developed during the second year of the project. The integration of the SPL tool into the SDE platform is a work in progress.
Progress and Integration. In the third year of the project, we have completed the porting of XXX, an earlier version of the tool in OCaML, and we have also defined the general structure of the plug-in that can be used to integrate new calculi/languages. In the next year, we plan to integrate a stochastic extension of SCEL. Moreover, we plan to complete the integration of the jSAM into SDE.
