Methodology

The methodology the Open License Society develops will encourage top-down development with full coherence between the different activities. This is similar to but different from the so-called V-method. At the same time bottom-up changes will be propagated to the higher levels assuring a contant feedback loop in the development process as well as allowing incremental development in small steps.

A white paper is available on request. If interested, please contact us. A 2 page flyer can be found here.

Interacting Entities

A key element in the envisioned methodology is the concept of ‘Communicating Objects’ or sometimes called ‘Interaction Oriented Progranming’ in the concept of software development. Concurrency and communication are key while this apporach has a formal background with the parallel process algebra CSP (Communicating Sequential Processes) pioneered by Hoare in the 70’s and meanwhile extended by others, even in different formal methods. CSP was also the basis of the occam programming language, now combined with Pi-calculus to support mobile processes. Also our own Virtuoso RTOS got it roots in these concepts and the same concepts are now applied in the development of OpenComRTOS. The communicating Objects approach when used consistently at all levels (specification, programming environment, model building, hardware) has major benefits like scalability, portability and information hiding. More details can be found in the White Paper. The following diagram provides a summary and possible use.

Why is it needed ?

The answer is simple. Economics. Engineers have learned to build bridges that very seldom fail. Why ? Because construction engineering has become a mature engineering activity, which means the outcome is fairly predictable. Of course there are the exceptional failures like the bridge that had to be destroyed after it was discovered some engineer had made a sign error, resulting in the steel reinforcements to be placed at the top, not at the bottom of the concrete. Further analysis could classify it as an oversight in the human-machine interface or simply incompleteness of the computer program. In (embedded) software, still about 50 % of all projects fail because they are not within 30 % of the pre-design expectations. This practically means that if all other parameters are kept constant, we have room to double the economic output. Have a look at some statements collected on the web. They mostly apply to ‘software development’, but they equally apply to embedded systems development, where software is quickly becoming the dominating ingredient.

Tools

The tool chain, called OpenDesign, implementing the methodology will consist of 3 main tools :

OpenSpecs (available as beta version) : for supporting the capturing of system requirements, functional and non-functional specifications, defining test criteria for acceptance and defining the “block-level” components of the system. OpenSpecs is derived from Tofs, a requirement capturing an specification building tool developed by ROMET AB (www.romet.se) in Sweden and has been used covering domains like : small embedded systems, C4SI, OpenSpecs itself and more. OpenSpecs aims at supporting system developers and stakeholders in defining the requirements and specifications of a system to be developed. It integrates the major activities in one single software program :

While the original Tofs is based on the Objects For Systems (O4S) methodology developed by Ingmar Ögren, it also has some roots in the Object Orientation of ADA. Nevertheless, it supports as well the Interacting Entities approach advocated by the Open License Society. During workshops with Ingmar, it was already determined that a transition to pure message passing between system objects would constitute a significant and meaningful simplification, resulting in a cleaner systems grammar and less ambiguity. OpenSpecs allows its users to use this paradigm. In some test runs it was found that the methodology can be applied to a very wide range of systems. In particular with OpenSpecs the system is not restricted to the 'system under development' (e.g. the embedded systems box), the methodology also defines the (human) operators, sensors, controllers en even the environment as part of the system.

In 2005/2006, OpenSpecs was redeveloped based on a more rigourous "systems grammar" as a web based tool, allowing team collaboration over a network. This second release of OpenSpecs is available. An individual membership gives you source code and a fully working version for 2500 euro. For details, contact us.

OpenObjects : for supporting the functional decomposition and composition of the system under development. The output is an executable specification. Executable means that the system can be logically simulated albeit the timely behavior is likely not correct and various input and output parts are simulated by software processes. This tool will also connect with the existing tools on the market and can be customized for specific application domains. In this domain simulation and model building is very important. For formal model building and checking, Open License Society has been using TLA+ with the TLC model checker of Leslie Lamport. See http://research.microsoft.com/users/lamport/

OpenComRTOS : although the environment will also target publicly available RTOS and other runtime environments, the Open License Society is developing an Open License distributed RTOS. This is needed to assure that the semantics and API allow seamless integration, compatible with the semantics of the other tools. Being the key component in the methodology, its development is done using formal analysis and validation using TLA+ and TLC. The first relase in August 2006 has confirmed the strength of tghis approach. Not only is the resulting architecture very small allowing codesizes below 1KBytes, several safety and security features were discovered and added. For details contact us.

In all cases will there be a constant and bi-directional feedback loop between the tools. Changes at the lower level will be annotated at the higher levels and vice-versa by the automatic code generation. The tools are designed to be used stand-alone as well. Above tool chain will be supplemented by embedded target platforms under the generic name of OpenPlatforms. While often coming from third parties they will be made available under an Open Licensing scheme and serve as reference platforms for developing domain specific applications.