Search My Blog & Website

Thursday, September 06, 2007

Daddy I Want a Cat Now: A Real-Time System Delimma

It was the first week of school when my daughter came back from school and dashed through the door to remind me of the promise I made last school year. I promised her that in the fall we can buy the cat she always wanted. I was faced with a real-time problem. I had to make a decision on the spot to accommodate her request. The 8 year old has been patiently waiting for 3 long months to invite that little creature into our home. Opposed to the idea of having one, I had to delay until she can prove herself responsible to care for little kitty.

So as humans we get faced with real-time problems, and we need to deal with them in intelligent ways to avoid long term damage, and short term devastation. The human real-time system shares some similarities with a real-time software system processing delay-sensitive service requests.

So what are the key attributes of a real-time system? In a nutshell it is a system that must produce accurate computational results and these computations must conclude within a predefined period. These two attributes are known as the functional correctness and timing correctness of the system, and both have equal importance.

Another key aspect of a real-time system is that is has awareness of the environment in which it exists and applications it hosts, hence it is considered deterministic as the responses to service requests are time bound. This deterministic response behavior makes a real-time system less adaptive to changes in the environment. We can easily see the dilemma faced by real-time systems operated in highly dynamic environments. A balance needs to occur between the deterministic response and the adaptiveness of the system.

The same applies to a parent's situation with his/her child, a deterministic response is needed and expected by the child. After waiting all these months for kitty and behaving well during the summer break, the child expects a real-time response. The child will not expect "ok, let me think about it". A decision has to be made on the spot, hence the time boundness. Additionally the parent is aware of the consequences of denying or approving the request. In the former case the child will be devastated and will accuse parent of not holding on to promises, in the latter case kitty will go on hunger as the child is still not responsible enough to care for kitty.

This kitty real-time system involves (1) a service request initiated by the child to own a cat, (2) a decision-maker processor - the parent - and (3) the external environment - the child's attitude. Do the laws of embedded real time systems apply here? They probably do, however it is a lot more complex than a technology real-time system such as a missile defense system and involves psychology, social behavior and various other domains of art. A missile defense system involves a human element in the decision-maker process to fire or not to fire, however the system element expecting the real-time response is not a human, it is a missile launch pad, and its behavior is well understood. In the example of the kitty, the child's behavior to the parent's real-time response is not clearly understood, it could manifest itself in a sudden outburst of tears and crying, an acceptance accompanied with long term dissatisfaction, short term happiness, etc... modeling and predicting human factors is a whole other story...

Common Software System Development Methodologies

There are 4 common software system development methodologies. These methodologies comprise of:

(1) A process - to define activities or tasks to achieve the goal of the methodology
(2) A vocabulary - to describe the process and work products created during the process application.
(3) Rules and guidelines - to define the quality of the process and the work products

The four methodologies are shown in the table below along with their strengths and weaknesses.







- Incremental and iteration

- Execution for verification

Scenarios and simplicity

Simplicity, design through integration and refactoring


- Comprehensive

- Well Defined artifacts and roles

- Incremental deliveries

- Simulation capability

- Well defined testing rules

- Well defined transition from one step in the process to another

- Real-time system support

- Simplicity

- Easy to use to transition from procedural to object oriented concepts

- Focuses on object value, leading to optimized system

- Focuses and cares about the programming environment

- Supports and requires close relationship between clients and developers

- Accounts for changes in the development process


- Large and difficult

- Complicated rules

- Customization is not straight-forward

- Limited vendors supporting the process

- Considerable learning curve

- Focuses too much on state modeling.

- Limited vendors supporting the process

- Supports primarily classes

- Requires a facilitator

- Relies on an ideal development environment

- Depends extensively on client commitments

- Requires high quality human interaction among development team

- The system is in a constant state of maintenance