Open License Society ______Only software can be perfect

Thoughts from the Open License Society one year after its foundation

Founded in the first month of the year 2004, Open License Society put its focus on system engineering methodologies and associated tools.

We studied and learned a lot. The gap between the state of the art and the state of the practice is wide. The latter results in some 50 % or more of the projects failing. At the same time we are happy to see that developers have started to use more rigor aiming to improve that figure. Actually, the problem as identified by numerous studies is not so much due to developers making errors (we banish the use of the term 'bugs' unless errors are blamed on someone else) but due to requirements and specifications being ill-defined, incomplete or plainly contradictory. The human factor still defies logic.

And while software is becoming the most important ingredient in all those systems, the essence is not limited to software intensive systems. Virtually any domain from social to scientific covers the development of systems. The key to success is formalized thinking. The latter is literally being applied using formal methods in software development. While still mathematical in notation and still seeking front-ends for the rest of us, their use has proven to provide substantial gains when applied. Rather than testing exhaustively and never finding all errors, formal techniques can deliver error free software even before implementation has started. The same applies to domains outside the traditional engineering domain and where more 'soft' - read human and social - properties come into play. The essence is to think in terms of the system, reducing it to its essential properties and stripping away any unnecessary ballast. Keep It Simple but Smart. Formalized thinking just helps. If the solution feels complex, just assume the problem itself was never really understood well enough.

As to the embedded market, the complexity wall is looming. After having reviewed a few technology roadmaps, it is clear that a radical change will be needed to tackle it. This change will need to start with the way we educate our embedded systems engineers. Rather than teaching specific tools and technologies - often obsolete by the time many engineers enter the industry - we need a shift towards better conceptual thinking and methodologies. But that also requires more exposure to real-world projects with real-world constraints. The market itself also needs to take a step back and reconsider its status. Do we really need a myriad of different processors, tools, programming languages and application specific hardware to develop the systems and appliances the end-market needs? The complexity wall is there because especially silicon technology is evolving much faster than the tools and methods we have at our disposal, and that includes the human brain that still has a hard time coping with more than 5 items at a time. The key in my opinion might be to take a radical step and to redevelop virtually from scratch new technology components with a few conditional constraints to measure its success :

• simple: a clean but powerful model as a start;
• formally based: how else can we verify that the system and its base technology components are 'trustworthy'?
• fault-tolerance designed in: cheap to achieve at design-time, horrendously expensive to add later on.
• scalable: in space and time (this missing attribute is perhaps the main reason for the complexity wall).

I could derive from these four requirements other such as low-power, concurrency and communication build in at all levels, modeling rather than programming, portability, etc. but I prefer to leave these elaborations for another time. Note however that if we look at the attributes of the original CSP-model and its derivatives, including languages like occam and processors like the transputer, we already have a good starting point. With hindsight, the transputer and its concepts was perhaps too early for its time and while the technology was proven to be working as a marvel, the way it was marketed has killed it. Perhaps it is time to pick up the threads and to reinvent it.

The first project of the Open License Society towards such a unifying methodology is the development of the OpenComRTOS, a key component of the system development methodology promoted by the Open License Society. It is key because its semantics will determine the semantics of all other tools like OpenSpecs of which we start the re-development in 2005. The whole methodology itself is now part of a FP6 project proposal at the European level and focuses on the concept of 'Interaction Oriented Programming', the latter expressing better what we called the 'Communicating Objects' approach. These activities are the basis for our commercial activities, aiming to deliver Trustworthy Embedded Components. The latter mean reliability, security and safety by design with the goal of delivering error-free application components.

Open License Society starts formal software development activities aiming at ‘Trustworthy Embedded Components’.

One of the aims of the Open License Society is to foster the use of better system development methodologies. In the first year we have put the emphasis on system engineering aspects, mostly through our workshops. Often the crucial point in this domain is requirements and specifications capturing. A formalized approach that takes into account all stakeholders is essential. The difficulty lies in the human factors. e.g. communication to get it right.
In system development however, the crucial elements are more and more the software components. If a system fails in the field it is most often the software that failed. Often the failure will be the result of the system reaching an illegal state that the developer did not anticipate and the test programs never reached it because they were never written for it. But when the system reaches it, often it will be at a very unwelcome moment resulting possible even in life-threatening situations like for the driver of a Renault car a few weeks ago whose cruise control blocked the car for 200 km at 190 km/hour. Fortunately, this time nobody got hurt.
It should be emphasized that the software engineers themselves are not really to be blamed. User level requirements will never be complete and accurate enough. In order to catch these illegal states before they actually occur, formal methodologies have been developed. While originally difficult to use unless one was a mathematical expert, this is changing and front-end tools are now becoming available to hide the mathematics. By using formal methods, we benefit on several levels: firstly it allows to catch errors before they are even programmed, secondly they often results in simpler as well as more powerful designs. The reason is that when building the formal model, overlapping and superfluous functionality is eliminated resulting in possible very clean designs.
At the Open License Society the emphasis is on developing applications using such formal methods, but mostly to develop ' Trustworthy Embedded Components'. Indeed, a major issue in the reuse of IP paradigm is the question whether one can trust the IP component acquired from a third party. Even if you have access to the source code, there is no guarantee. The only solution is to have access to the formal analysis and validation data as well as to the source code. Note however that while certification after the component was developed increases the certainty, it does never provide it fully. Certification in itself does not correct undetected errors. Hence our goal is to develop 'trustworthy embedded components' with three major qualities:

1. Reliability or correctness of operation as specified.
2. Safety or the capability to operate correctly even when system failures occur.
3. Security or the capability to shield the application from intrusion or externally induced failures.

This is an ambitious roadmap but a necessary one if the embedded systems industry wants to increase its success rate and not be stuck hitting the wall of complexity.
A first component in this development is the OpenComRTOS, our distributed runtime environment we envision as crucial for the systems development methodology based on Communicating Objects we advocate. This development is partly funded by a Flemish government grant issued by IWT.
In this context Open License Society is looking for:

- Potential users to be part of the user review panel;
- Kernel developers with a strong mathematical inclination.

If interested, contact eric.verhulst (@) OpenLicenseSociety.org

Impressions from INCOSE 2004 (June, Toulouse)

From 21st June the INCOSE conference took place in Toulouse. INCOSE, now featuring over 5000 members world-wide stands for 'International Council on System Engineering'. It featured several workshops, parallel conference presentation tracks and visits to Airbus and Actatel Space bringing together some 600 people from all over the world who are involved with various aspects of system engineering.

While system engineering has been done since people exist, as a discipline with a scientific and technical foundation, it is still a fairly new one, as demonstrated by an on-going discussion on terminology at the conference. Its domain covers many aspects ranging from early concept development over analyzing the economic feasibility to providing disposal services, decades after the system or the products has been put in service. As such, system engineering is the discipline of dealing with complexity across multiple domains, including human factors although its principles are valid for small-scale projects as well. Traditionally systems engineering has focused on project management issues. The emergence of embedded systems in all aspects of society with an increasing role attributed to software is changing the focus to the whole life-cycle of the system, to more quality in the development and to a greater need for dynamic changes even during the development. Traditional project management often starts from the system definition as a given with the objective to bring its development to a good end within the boundary conditions of time and resources. The new view of systems engineering is that it starts when a need or opportunity is perceived; all stakeholders get involved and remain involved during the whole lifetime of the system. This means that technology is no longer perceived as an end to itself, but as a potential tool to address the real issues. The dominant factor has become the human factor and the environment in which the system will be placed. Research has show that while still a large number (at least 50 %) of all projects fail to deliver, the principal reason is the lack of clear requirements and specifications phase whereby all stakeholders remain involved. A clear example of this was given by a special session on security. While technical solutions were proposed to e.g. combat terrorism, the final conclusion was that the roots of the problem - often at the political and socio-economic level - need to be addressed as well. As a result the traditional waterfall method is no longer deemed adequate and combinations of V-method with spiral-engineering are now becoming the norm.

Another trend, especially for embedded systems, is the emerging use of formal methodologies. The main reasons are the increasing degree of interconnectivity between de cooperating sub-systems and the need not just for quality but also for security and safety. E.g. modern cars have now tens of processors and we all know the stories about newly developed models that failed for non-trivial reasons. Most often, the real reason was an unexpected sequence of events that was not anticipated during the development of the car's control logic. Formal methods can detect such conditions even before the system is developed while traditional testing techniques can never find them.

Modern system engineering has it roots in the defense and aerospace industry and this was well illustrated by the visits to Airbus and Alcatel Space. Particularly Airbus demonstrated a great mastery of the process. Just a few examples. The safety critical software on the Airbus is automatically generated from a high level specification by a certified compiler. It covers 70 % of all code and until now no error has been found. As a result, the airbus is one of the safest planes in the world. The production process is also very well streamlined and can produce a new airplane every day. Parts are manufactured at several locations across Europe and then assembled in Toulouse. Just two weeks after the plane is assembled, integration tests are done and the plane takes it first flight.

The Open License Society is focusing on system engineering methodologies and proposes workshops and training on a regular basis. The Open License Society is now also starting up a Belgian Chapter of INCOSE. If interested, contact eric.verhulst (@) OpenLicenseSociety.org The website of INCOSE is to be found at www.incose.org

SysML, a new standard for systems engineering drafted

Currently it is common practice for systems engineers to use a wide range of modeling languages, tools and techniques on large systems projects. In a manner similar to how the Unified Modeling Language (UML) unified modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.

INCOSE as well as OMG are working on a new standard called sysML to cater for the needs of system engineers. The Systems Modeling Language (SysML) specification is a general-purpose systems modeling language that supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, data, personnel, procedures, and facilities. This specification is being aligned with the evolving ISO AP-233 data interchange standard for systems engineering to support interoperability between systems engineering tools and other tools that interface with them.

A UML-compatible systems modeling language will support the exchange of information using standardized notations and semantics that are understood in precise and consistent ways. This will improve communication among the various stakeholders who participate in the systems development process and promote interoperability among modeling tools. It is anticipated that SysML will be customized to model domain specific applications, such as automotive, aerospace, communications and information systems.

It should be noted however that sysML just as UML is mainly a graphical notation language for which the standards are defined. E.g. a serious missing element from a methodology point of view is a formal definition. Nevertheless, it is a step in the right direction as such an informal notation is a first step towards full formalism to remove ambiguities and errors that informal (hence based on natural language) generate. SysML is already taking some steps by only using those notations of UML2 that are consistent and creating new types of diagrams for the system s engineering views that are missing. More details at www.SysML.org

What are Communicating Objects anyway ?

A major issue in systems design is language. Language, because that is what we use to express ourselves and communicate with each other en in systems development the human factor is important. The problem with natural language is that words have no ambigious meaning and worse, because we often use a common language - often english - to bridge the curtural gap, each one of us has a cultural context that can modify the understanding of the words. In addition, system design brings together stakeholders dfrom different fields, each again with their domain specific habits and expressions.
As to the core concept of 'Communicating Objects', this will have slightly different interpretations depending on who your are. In our concept, another term could have been 'Communicating Processes', as the formal concept behind it is CSP (Communicating Sequential Processes from C.A.R. Hoare), but that give us a high association with concurrent computing, whereas an object can effectively be anything, even a human person or hydraulic subsystem. Another term could have been 'Communicating Agents' with refernece to the field of Agent based computing. Conceptually this is closer, as Agents are defined are fairly autonomous entities that communicate with each other and whereby system properties emerge as a result of their interaction. It is definitely the right paradign to simulate a real system that includes the environment, human operator and various external subsystem. The concept agent however is associated with artificial intelligence and might sound funny to an embedded systems developer. Hence we opted for the term Communicating Objects, although somebody else called it 'Co-operating Objects'. We believe that the use of Communicating Objects is the closest to reality and carries the right level of abstraction. We try to define more clearly what behind it:
Objects are consituent entities that can be used to compose a system at a higher level. Objecvts can have a behaviour like processes, but can also be fairly 'passive' components (e.g. the body of a car). What glues the objects together are their dependency relationships and their messages. Messages are the means used express how objects interact. At the abstract level messages are mostly a protocol between objects, independently of the carrier of these messages. Hence at that level, the only interaction between objects is through a message passing protocol. The latter can be specified at a very abstract level, as found e.g. in semantic networks. By adopting this approach, objects become completely self-contained units featuring full information hiding. Nothing of its internals of implementation are visible or assumed, except that it accepts or generates messages with a well-defined protocol. Even if some of the internals are exposed, this will be through an explicit message. Note however that once the development process starts making implementation choices, messages can be mapped onto specific functions calls or in the case of e.g. mechanical subsystems, force transfers.

Systems Grammar

In the recent workshop on Requirements Capturing and Systems Specifications for Embedded Systems with Ingmar Ögren, OpenSpecs was used for a small hands-on exercise. Part of the workshop was to highlight the issue of the definition of terms. At the Open License Society we call this the systems grammar. It corresponds with the meta-model that will be implemented in the central repository. This is an important activity as its goal is to find the minimum set of concepts that cab be used to describe and specify any system.
It is comparable to the definition of the instruction set of a processor. The ideal instruction set will be as small as possible but must be complete to cover all computational requirements. It must be orthogonal as well as this simplifies the resulting architecture and simplifies the challenge of generating efficient compilers. In a systems grammars this relates to the definition of a database using entity-relationship definitions. Entities are the fundamental building blocks, their relationships constitute the architecture and influence the development process, while their attributes allow to qualify the types of the entities. A systems grammar however is not only about system objects and how they constitute a system. It has also to support different views : the requirements and specifications view, the architectural view and the project view being the main ones. Each view uses the same objects but arranges them in different sets and with different relationships to reflect the different aspects of the whole systems development process. A draft of the systems grammar is available for download here Feedback is welcome.

Open License Society Membership

As the Open License Society is a non-profit reseach institute, it features membership. Indiviual membership gives you for 2500 euro OpenSpecs (with source code), an open channel to discuss system level development issues and a 20 % reduction on the workshops. Corporate membership and sponsoring members get in addition a seat on the scientific committee and can contribute to the roadmap. Contact us via the registration page.

OpenLicenseSociety vzw
Research Institute for Systematic
Systems Development Methodologies
http://www.OpenLicenseSociety.org

Contact : info.request (@) OpenLicenseSociety.org