Subscribe to the latest news!

Developing a system is perhaps one of the most challenging tasks. While often associated with engineering, it actually covers a very wide domain. A system might be a small chip that is composed of multiple modules when looked on the inside, it can as well be a world-wide transportation system as it can be a social and political organization. Typically developing a system is done by experienced people and requires the input of all of the stakeholders such as policy makers, management, users and yes, also the development engineers. As this is such a wide domain, the Open License Society will first focus on the domain its founders know best : embedded systems.
Embedded Systems can be defined as systems or devices that accept data from sensors, process the signals in digital form, often in real-time, and generate appropriate responses. Such embedded systems contain a processing engine with a minimum amount of computing power. They are increasingly becoming part of our living environment. A great multitude of embedded devices is being applied in very different shapes and applications. Nevertheless, about 50 % all development projects fail. Hence the economic stakes are high.
While the above definition equally applies to general-purpose desktop or server computers, embedded systems are typically characterized by a specific functionality in a specific domain (although personal computer are being used as part of an embedded system). In addition, embedded systems are often designed with strict boundary conditions of power consumption, size, cost price and reliability. While the first characteristics are often a matter of selecting the appropriate technology components, applying the technology and making sure the embedded system will meet all functional and reliability requirements is a matter of correct system design. Part of the challenge for the embedded systems developer is that each embedded domain has its own history, the diversity is wide and there a lack of a unified engineering approach between the domains, even if from a functional point of view the similarities can be very high.
The Open License Society as a R&D company is aiming at developing and promoting a coherent unified system design methodology that is accessible, reliable and cost efficient. As a research institute the social aim is to function as a center of excellence and to promote the developed methodology to a wider industry to increase their productivity and competitiveness resulting in embedded systems of higher quality and reliability. As a research institute, the Open License Society aims to cover the whole domain from the cognitive processes that govern the engineering methodology to the generation of reference platform designs. The aim is to develop an integrated methodology and a supporting tool chain that covers the path from first idea to implementation, albeit in an incremental way.
In order to achieve a wide adoption an affordable open licensing model has been introduced for the core tool chain, associated reference platforms, complemented with activities of training and general education. The core products, some of them developed by partner companies are marketed under the umbrella of ‘ Trustworthy Embedded Components’. The adoption of the methodology in a systematic way allows creating a large momentum as third parties can pro-actively develop complementary tools and reference platforms, with the institute focusing on the methodology itself, the core tool chain and application level trustworthy, fully compatible components.
As a research institute the Open License Society researches and develops a unified, coherent and cost-efficient development methodology for systems, with an initial focus on embedded systems.
The Open License Society will make available the core tool chain consisting of OpenSpecs, OpenComRTOS and OpenObjects as the main ones.
Under an Open Licensing scheme these will be made available at affordable licensing fees with access to source code for a wider community of embedded developers. Under the Open License scheme complementary tools and reference implementation platforms will be made available as well.
The Open License Society welcomes third parties and corporate sponsors to join this unique approach to better embedded systems design.
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:
Answer: The Open License Society is a R&D company aiming at greatly improving the process used to develop systems. The initial approach aims at providing the core tool chain centered around the concept of Communicating Objects, complemented with third party tools and reference platforms.
Each tool is made available to a wider member community under the terms of the Open Licensing model, with access to source code and all design documents. With design documents we mean all documents generated during the development phase, a user manual and if applicable the formal analysis and validation.
Answer: An Open License reconciles the benefits of an Open Source license and a Commercial license. An (individual) licensee is a member of the Open License Society and subscribes initially for one year receiving a copy of the licensed product with 'an eternal right to use' including access to the source code, design documents (including formal analysis and validation when available), test harnesses or production data (in case of hardware). After one year he can continue to use the license 'as is' or renew the annual membership and subscription for having access to upgrades. The license restricts the licensee to use the licensed product for application developments only. The Open License Society remains at all times the owner of the licensed product and the derived versions that can be developed by licensees. However the Open License Society can integrate the changes in the licensed product. The licensee is also free to develop complementary or derived tools for as far as they are compatible and the Open License Society can add these (under a non-exclusive Open License agreement) to the toolchain. Subject to change.
Why is it needed ?
Answer: According to various research sources, about 50 % of all projects fail. This applies to embedded systems as well as to ICT systems. Some sources even quote more than 70 %. If however all systems developed would be considered (including social and economic) the failure rate is likely higher if also the cost overruns would be included in the evaluation. Most projects seem to fail because all stake holders were not enough involved in the process of developing the system. This highlights the human factor. On the technical side there is a lack of tool chain that covers the whole process or worse, development organisations are forced to often manually integrate various incompatible tools. The underlying reason why the integration is so problematic is not so much technical, but at the semantic level. Therefore the first activity the Open License Society focusses on is on de requirements capturing and specification phase whereby we first define the meta-model. The latter is called a systems grammar and has to be seen as the universal language in which all systems can be described.
Enlightening quotes from a few web searches
Note: A remarkable observation. While many references showed up pointing to software developments, few speak explicitly of embedded software. Nevertheless, we believe that the conclusions apply.
1. The Standish Group
72 % of all software projects fail. [The Standish Group, 2000 CHAOS Report]. Regardless of your industry, you are in the software business. Software is integral to every business, large or small. Not creating the software you need is expensive, measured in lost productivity. Creating the software you need is also expensive, often two or three times more expensive than it needs to be. Outsourced projects can be even more expensive than ones done in house.
A study in 1999 by the Standish Group of large commercial and government systems in the US showed that only 16% of enterprise applications were completed on time and within budget; for 53%, the cost growth exceeded 89%; and 31% were canceled. Of those completed, only 61% of specified features were included.
2. Often the problem is not lack of talent, it's lack of knowledge:
The executives don't know how software should be built, so can't monitor the process. The managers don't understand the needs of the programmers, so can't help them work effectively. The programmers understand the nuts and bolts of the technology, but don't know how to use the technology effectively. Even when you get the knowledge, you don't know how to use that knowledge effectively.4. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little."
-David Parnas5. "The structure of a system tends to mirror the structure of the group producing it."
-Mel Conway6. "If good software engineering were really all just common sense, we should expect to see projects routinely meet their schedule and budget targets and delight their end users."
-Steve McConnell7. "Many people tell the story of the CEO of a software company who claimed that his product would be object oriented because it was written in C++. Some tell the story without knowing that it is a joke."
-Adele Goldberg8. There are three critical success factors in a software project which are consistently ranked highest in industry surveys:
- clear requirement specifications,
- clear business objectives, and
- user involvement.9. The Standish Report on project failure (Standishgroup, 1994) identified the primary "causes" of failure and success in IS projects.
Ranked Project Success Factors were:
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff
Ranked Project Impairment Factors were:
1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn't Need It Any Longer
9. Lack of IT Management
10. Technology Illiteracy
10. Dilbert. And if that isn’t enough, there is still Dilbert, the antidot