Specification, Verification, and Adaptation of Software Interfaces using Eclipse ComMASuite

Software interfaces are key to realizing the benefits of component-based software architectures, yet specifying interfaces is difficult and may result in problems in the protocol specification itself, or in its interactions with clients. This problem is addressed through a six-step methodology for specification, verification, and adaptation of software interfaces. The methodology builds on the open-source tool Eclipse ComMASuite, developed by TNO-ESI partners in an open innovation eco-system. The specification and verification steps have been contributed back to the community and are supported by a two-day course named “Modelling and Analysis of Component-based Systems”, available from TNO-ESI in both an academic and industry version.

Please read my blog post that describes the methodology and demonstrates it step-by-step from a user perspective through a simple case study in a video.

Open-source ComMA v0.1.0 officially released

Last week, the open sourcing of ComMA (Component Modelling and Analysis) in the context of the Eclipse Foundation, saw another milestone. The first version Eclipse CommaSuite is now online in the form of Release 0.1.0. ComMA is a set of DSLs used to (partially) specify the behavior of components and their interfaces, including time and data constraints. On the basis of these specifications, a number of artifacts can be automatically generated, including run-time monitors that validate compliance with the specification can be generated, visualizations, timing statistics, documentation, test cases, and adapters. Many of these features will be included in later releases of ComMA, and some of them have yet to emerge from research projects as mature features.

ComMA was originally developed by ESI and Philips, but more recently in collaboration with a growing number of other companies. For example, the DYNAMICS project in which ESI works together with Thales, we are currently investigating how adapters can be semi-automatically generated to bridge differences between components implementing different versions of interfaces. This work has been previously mentioned in an article in Bits & Chips, as well as in a paper. Currently, three master students from my Embedded Software and Systems course at UvA are also doing their graduation projects in the context of evolution of ComMA interfaces, looking into aspects of data dependencies, interface dependencies, and static impact analysis. We look forward to seeing the results of their work this summer.

You can read more about ComMA in this news article TNO published this week.
Update: The news article is now also published in Bits & Chips

Embedded Software and Systems Course @ UvA Continues to Evolve

The fall semester of the very special academic year 2020/2021 is over. Most of the students following the Master of Software Engineering program at the University of Amsterdam have just completed my course Embedded Software and Systems (ESS). The ESS course had changed in a three important ways this year.

Firstly, a generic lecture about Petri Nets was changed to a series about two lectures, explaining how Petri Nets can be used to model and analyze software interfaces and components. Part of the material for this course was reused from the course Modelling and Analysis of Component-based Systems (MOANA-CBS), developed together with Thales targeting an industrial audience. These new lectures also prime students nicely for a lecture about the DYNAMICS project, a research collaboration between ESI and Thales. This allows me to show how these models and analyses can be used in practice to address problems related to software evolution by detecting incompatibilities and generating adapters when updating software interfaces. A generic lecture about the data-flow model of computation was removed to create room for this new material, but I am happy to teach fewer modelling formalisms and have more time to go in depth and show how they can be used to solve industrial problems. A nice result of this change to the course is that three master students have accepted thesis projects in the area of modelling and analysis of software components and interfaces in collaboration with ESI under the supervision of myself and my colleague Debjyoti Bera.

Secondly, the course project was redeveloped this year. Previously, students used Mathworks Stateflow to program Lego Mindstorm EV3 rovers to follow a line, avoid obstacles, and count objects. However, this project felt a bit too much like a toy and there were technical problems with both rovers and tools that were hard to overcome and limited the education experience. In particular, it was not easily possible to see or influence how code was generated for the Lego Mindstorm robots, which felt like a missed opportunity when teaching model-based engineering. 

Two bachelor students did their theses in spring to evaluate the suitability of using the TurtleBot3 Burger robot, both in reality and in simulation using Gazebo, in the course. In addition, Stateflow was exchanged for Yakindu Statechart Tools, which is easier to use and gives us the flexibility we need in code generation. The new application developed in the project is to use Yakindu to program the TurtleBot to autonomously drive through a maze and map it.

Lastly, the COVID-19 pandemic required the entire course to be taught online. As a result, used a blended learning approach and prerecorded the lectures so that the students could watch them when they wanted to. Online interactive sessions were added to the course where the students could ask questions about the lectures, and participate in quizzes and group discussions. Online teaching meant that the students did not have access to the four physical TurtleBots that we had purchased. Luckily, the newly developed course project could be done with simulations in Gazebo. Below is a demo from one of the groups that very successfully solved the assignment. 

The ESS course is continuously evolving and maturing and next year will be no different. Most importantly, we hope that the pandemic will be over by then and that we can put our three physical TurtleBots to good use.

Bachelor Thesis on Synthetic Interface Generation Defended

Mohammed (Mo) Diallo just defended his bachelor thesis entitled “Towards the Scalability of Detecting and Correcting Incompatible Service Interfaces“. This work is carried out in the context of a project between ESI (TNO) and Thales that developed a five-step methodology for automatic detection and correction of behavioral incompatibilities resulting from evolving software interfaces (see paper for more details). Mo’s thesis provides a starting point for evaluating the scalability of the proposed methodology. An essential ingredient towards this is the ability to synthetically generate interfaces of various complexity. The thesis has two main contributions: 1) a notion of interface complexity in terms of inputs, outputs and non-determinism is defined and the relation between these parameters is studied, and 2) the methodology for a ComMA interface generator using user-supplied complexity parameters, and its implementation in a supporting tool, is introduced.

I would like to thank Mo for the excellent work he delivered in this thesis, and I am happy that he will continue working over summer to extend it.

DRAMPower v4.0 Released!

A new version of the DRAMPower tool has been released. The two main features of version 4 are:

  1. DRAMPower can now be compiled as a library. This enables a user to access the tool through an API and log commands and their corresponding time stamps, removing the need to store large command traces on disk. The key benefit of this feature is that users can easily integrate DRAMPower into their own memory controller simulators and obtain power and energy consumption estimates. In fact, this version of DRAMPower is already integrated into the memory controller of the gem5 simulator system and is provided with the latest release.
  2. Improved robustness. The latest build is checked out every night on a test server, compiled, and tested to verify that the output matches an expected reference for a battery of tests. The code is also compiled with a large number of warning flags enabled and treats all warnings as errors. This feature makes it easier for the community to reliably contribute to the tool, which is now possible through github.

Check it out the new version of DRAMPower here.

RTMemController v1.0 Released

The Memory Team is proud to release another open-source tool to the community. This tool is called RTMemController and contains a mathematical formalization of the dynamic command scheduler introduced in Yonghui Li’s paper Dynamic Command Scheduling for Real-Time Memory Controllers that will be presented at ECRTS. The tool is capable of determining worst-case and average-case execution times of memory transactions of different transaction sizes and with varying degrees of bank interleaving.

An important driver for releasing this tool is to promote transparency and fair comparisons between work in the field. Longer term development plans for the tool may involve adding support for a memory controller front-end with different transaction schedulers, adding support for more memory generations (currently DDR3 is supported), and making the output compatible with DRAMPower to enable chaining the tools.

The official website of RTMemController is found here. Also check out the paper that describes the scheduling algorithm and its formalization.

DRAMPower v3.1 Released!

The latest version of the tool now includes IO and Termination power measures from Micron’s DRAM Power Calculator for all supported DRAM generations. This feature enables support for power estimation of dual-rank DRAMs (DDR2/3/4). Additionally, new warning messages have been added, to identify if the memory or bank state is inconsistent in the user-defined command traces. This release also fixes minor bugs related to Precharge All (PREA) to improve the accuracy of DRAM power estimation.

Check it out here.

DRAMPower v3.0 Released!

DRAMPower v3.0 has been released! The tool can now be employed with two interfaces: (1) Command traces and (2) Transaction traces (new feature). To facilitate usage of memory transaction traces, DRAMPower now includes an optional DRAM command scheduler, which dynamically schedules and logs DRAM commands, corresponding to the incoming memory transactions, as if it was connected to a memory controller. The scheduler assumes a closed-page policy, employs FCFS scheduling across transactions and uses ASAP scheduling for DRAM commands. This release also adds support for DDR4 and LPDDR3 devices and fixes minor bugs to improve the accuracy of DRAM power estimation. Click here to check it out.

DRAMPower v2.1 is Available and Variation-aware

The DRAMPower tool has been updated to v2.1 with support for variation-aware power estimation for a selection of DDR3 memories, based on the analysis presented in our DAC ’13 article. Towards this, 15 sample datasheets reflecting the impact of process-variations on DRAM currents have been added to tool.

For more information, or to download the tool, please refer to the official DRAMPower website.

DRAMPower v2.0 Released!

The new version of our tool for fast and accurate system-level power estimation of DRAMs has been released. This version features many important improvements, such as significantly improved analysis speed (at least 10x), enabling analysis of much larger traces, as well as support for LPDDR/LPDDR2 and Wide I/O memories. The results of this version have furthermore been verified by Kaiserslautern University of Technology using equivalent circuit-level SPICE simulations, which established that the error of the tool is < 2% for all memory operations of any granularity for all memories supported by DRAMPower.

For more information, or to download the tool, please refer to the official DRAMPower website.