Safety engineering standards

The first domain where engineering was applied is in the safety domain. Naturally, lives are at stake and failures can be catastrophic and expensive. Standards like ISO-26262, IEC61508, DO-178C have pioneered and make way for a systematic approach to systems engineering.†

Engineering services

Altreonic puts is experience at work by providing its customers training, supporting tools and services. Especially for new projects, the transition to a formalized methodology can be daunting. However, once the concepts are understood, the complexity disappears to make room for a new insight.

Why a formalized methodology is paying off

Traditional bottom-up development can sometimes gives a quick first result. This can be a good approach for quick prototyping, but it carries a high risk to use this approach for a production version. Incomplete and contradictory requirements will creep up in the architecture, resulting in issues during testing or worse in production. This shows up as a high risk in run-away costs as the cost of changes can skyrocket. A formalized approach on the other hand, will shift the shift the work upfront where making a change is often just a matter of thinking things through and making the changes in the specification or computer models. A such a high reliability driven design can easily have a lower lifecycle cost.

Safety system properties

Safety can not be bolted onto a system like an afterthought. It is not provided by any of the subsystems, be it hardware or software. Safety is the result of a well thought out system architecture and can only be reached by following a systematic and formalized process.

Service domains


 Formal model checking and software verification

 Embedded software development

 Customer specific adaptations of Altreonicís software tools.