24 June 2011

The base for functional safety: Requirements

There are several myths around functional safety. So it is said that functional safety processes let the project costs grow. As it is true for so many things in the software or system lifecycle, if functional safety activities are not full integrated in all steps of the lifecycle, then it does it more worth than good.

So surprisingly, functional safety starts with requirement engineering ! Requirements are describing the system as it should be, and therefore, they are the base for verification and validation of the system. Roughly said, verification means to demonstrate that the system fullfil the requirements. Simple consequence: no requirements, no verification possible.

Validation means to demonstrate that the requirements are stated such that the system is usable as intended in its operational environment. But to check this doesn't make any sense if the system could not be verified. Conclusion from a wrong preposition gets nothing.

Later activities of the functional safety identify risks which arise if the system goes operational, and which additional functions the system are needed to mitigate the risks down to an acceptable level. Example: a cutting machine induces the risk that you get you hand cut off if you pull it in in the wrong moment. So the mitigation would be a protection system that would stop the machine immediately if any body part crosses a safety border.

Such additional system functions or properties will be noted as additional requirements. And checking if the system is safe includes to verify these safety requirements.

Conclusion: much effort of the functional safety activities can be done efficiently if there is a good requirement engineering in place. It helps to verify and validate the system according the safety functions and the overall safety and to render which are the safety relevant parts of the system.

But how requirements stated will be issue of another post, because this is very important for the value of requirements.

Enjoy !

15 June 2011

The Browsers Future

Today, the web browsers are on the road to become omnipotent: beside the ability to display text they now render complex graphics and video. So many examples in the Web exist providing the user Web pages which are close to pages of an expensive life style magazine with respect of their presentation quality.

Also, browsers are already an runtime environment. See Flash(TM) and JavaScript for example. Look at all the games and interactive websites available in the internet. WebGL and SVG in combination with JavaScript bring you a full desktop like experience into the browser. So it is possible to run a Smalltalk environment in a browser. The current top of this evolution is Googles ChromeOS notebook, where in fact the browser is the operating system and the only thing the user see.

But this is the moment to start thinking in another direction. Why should a single application - the browser - get bigger and bigger ? I always dream about a software ecosystem, were small little code fragments in the sum give you the value. Every fragment, which may be an app or even smaller, has a limited role in the ecosystem and only their dynamic interaction let emerge the value to the user.

And this is the important term: interaction. Every fragment in the sense above shall have a range of processing capabilities. They shall not be limited to much, but broad enough to gain value for different non-forseeable situations. And we now all the solution for this: descriptive languages, like HTML, XML etc. In fact, a browser can handle many things by "just" implementing the HTML language. In the same ways, these fragments should implement one such a language, like SVG for graphics, X3D for 3D graphics, MathML for mathematics etc.

All this things exist, yes, but as one big bunch of software (that many things are implemented as plug-ins doesn't change anything substantially). My vision would be, that the fragments for SVG, MathML, CellML and what ever should be independent small code fragments, which could running on the local machine or anywhere in the network. In this software landscape, the browser would be just a collector and lay-outer of (ready drawn) canvases. And the communication between this fragments should be only ASCII text stream or a (video) stream of bitmaps.

Of course it is difficult to control a collaborative system in its emergent behaviour. But the main question for the future is: do we have to control all behaviour of future systems in detail ? Anyway, my wish would be that the future of software moves away from monolitic systems to a network of small fragments controllable just by descriptive languages.

Enjoy !

04 June 2011

Splitting my idendity

Twitter is for me a often used tool, not just to hear what's about in the world, but to get noticed about technology, events and to get connected to other interesting people.

Now, because I am also working on own Serious Games, which I call "Enriched Games" (which is a story not for this blog), and because I am a Safety Engineer with all parts of my being and feeling there was now the time, to split up my Twitter account in 3 theme centered accounts:

From now on, I have
  • @haenbee for all things of life, news, technology and science in general. It was my first account on Twitter, and I want to keep it for all the stuff which match not one of the themes listed below
  • @EnrichedGamesHB for all things about Serious Games (aka Enriched Games), including Seaside, Pharo and WebDesign and Computer Graphics. In fact, not just gaming, but all issues which are related to the realization of my games will be covered here. For my plans, I choose Seaside and SVG, because here I have the most experience (which is not much, either) and Smalltalk is still one of the most productive environments
  • @QuMeSA_HB, the account which is connected to this blog, and where I consider things about Software, SW Architecture, Modeling, Functional Safety etc. Especially I want to discuss about the problems I sketched in the last post.
A special role plays AI: also one of my interests, also for gaming, but this theme is really spread over all fields: it touches human being, gaming, software, science in the same time. So you will find AI issues in all three accounts until I have a better idea ;)

So feel free to follow me or discuss with me, I really be happy for every follower and discussion peer to talk about my ideas and of course his or hers. Discourse is one of the most important things, and the Internet today gives us the chance to really do this crossing any borders and culture.

Enjoy !



02 June 2011

Functional Safety of Software

Since 3 years, I'm working as a Safety Engineer. Starting in the Air Traffic Control domain, I now have to consider the functional safety of locomotives. So in parallel, my perspective is extended to physical, mechanical things, which is really cool.

Along with this evolution, my interest is focusing on the question how software has to be built in a functional safety related context. This is a question which strongly relates to the problem of how to overcome the human imperfection and avoid human errors in concept, architecture and in the whole technical realization of a system from the beginning. It is a question for methods, provability and well known and well tested engineering practice.

In consequence, today my view on modeling of requirements, system architecture and function networks as well as on the computer science itself has changed. I see now the challenge and the benefit of tool based software development in a different light. I see, that we need a information science, not a computer science. I understand, that we are still searching for the rules of information which correspond to the rules of physics in the mechanical engineering. Software Architects, Software Engineering, are terms with today expanded meaning.

Therefore, I want to add functional safety as theme for this blog, and this is well done, because metaphysics is the only hope to get further :) I will tell stories about communication from software engineers to safety engineers, the amusing stories as well as the horror at work.

So stay tuned :)