ComMA interfaces open the door to reliable high-tech systems

Once a research project initiated by ESI (TNO) and Philips, the ComMA framework is developing into a mature product for creating and managing software interfaces. Now, Thales is also looking to use it to streamline its software engineering, as are Thermo Fisher Scientific and Kulicke & Soffa. “ComMA is the place where you express everything you want and from there, you generate everything you need, like documentation, monitoring, simulation, visualization and, as of recently, test cases.”

“Our medical devices are growing bigger and bigger,” observes Daan van der Munnik, software manager at Philips Healthcare in Best. “We have to chop them up in smaller subsystems to keep their development manageable, but also for validation purposes. Up to a year ago, we validated a complete device in one go – a huge effort. By chopping it up in smaller subsystems, we can focus our validation efforts on the parts of the system we actually touch for a particular feature. We do need to show that when we put everything together, it still does what it’s supposed to do. Both the disassembling and reassembling call for good interface management.”

Source: Bits & Chips

Fellow high-tech company Thales faces similar challenges. “Traditionally, we developed, built and qualified our combat management and radar systems, delivered them to the customer and mostly touched them to replace obsolete components – to avoid unnecessary risks, functional changes were rather limited and implemented at long intervals,” explains Pepijn Noltes, software architect at the Hengelo-based company. The last ten years, however, the operational scene is changing more rapidly at extended operational lifecycles, with customers increasingly demanding new features. Thales is adapting to this need by looking for ways to implement software updates more frequently, including incremental enhancements.

ComMA (Component Modeling and Analysis) is an ecosystem supporting model-based component engineering. It’s a combination of domain-specific languages (DSLs) in which the interface between a server and its clients can be specified by three main ingredients: the interface signature, the allowed client-server interactions and the time and data constraints. The interface signature consists of groups of commands, signals and asynchronous notifications. Commands are synchronous: the caller is blocked until a reply is received, whereas signals are asynchronous: they do not block the caller and do not require a reply. State machines are used to describe the allowed client-server interactions, such as the allowed order of client calls and the allowed notifications from the server in any state. Finally, Comma enables the definition of constraints such as the allowed response time, notification periodicity and data relationships between the parameters of subsequent calls.