embedded Vs Realtime

Then what's the difference between a turnkey system and an embedded system? :-)

Which is still useful. Ie, a product I worked on was real-time in most ways, but there were no hard time limits. Instead, the more we could reduce timing variance the more bandwidth we could produce. The window size was arbitrary, but everyone knew that smaller was better, and that it would shrink on successive releases.

Similarly, the "penalty" for missing the timing was arbitrary too. A failure once an hour wouldn't be noticed without diagnostic tools, but a failure once a second would have significant degradation of performance.

Again, that's another orthogonal concept. Turnkey means you unpack it from the box, supply power, flip the "on" switch and it does whatever it's supposed to do -- regardless of whether that's provide general-purpose computer or some sort of specialized "embedded" function.

IOW, you don't have to install any more software or integrate any more hardware.

A turnkey system like a kiosk or cell phone or whatever may contain one or more "embedded" computers (or it may not).

I'd call something like a Macintosh a "turnkey" general-purpose computer.

I would say that the "event" model is too simplistic to describe RT - although "event driven" is certainly one way to implement such a system.

I prefer a transactional model for RT system because transactions easily handle nesting and overlapping processes. The event model can't deal with either adequately ... by the time you add the statefulness necessary to handle nesting and overlapping, you've either gone most of the way to a transaction model anyway or you've created something half-assed and very brittle.

I get the impression (and please correct me if I'm wrong) that you associate the term "real time" with a mind set that focuses irrationally on time to the exclusion of other design issues. That could not be further from the truth.

It is proper to refer to any system which has time aspects to proper operation as being "real time". Such a description only implies that time is an important aspect of the system's operation.

Timeliness is rarely the "utmost importance" of the system. The "importance" is usually described by phrases like "pace the patient's heart", "control pressure in the reaction vessel" or even "pump bits serially onto wire".

The holistic approach breaks down rapidly as the number of failure modes increases. In a complicated system each failure domain has to be evaluated separately and then the domain interactions must be analyzed.

My point is this:

The engineer performing risk analysis or mitigation must understand the concepts involved separately in order to deal with them mixed. For example, the timing implications of a software design are completely unrelated to the EMI risks to the hardware assembly.

An engineer dealing with a time aspect system has to understand what RT means, both in the abstract to design and understand the system and in the concrete to deal with actual time aspects of the implementation.

There is a big difference between the operational understanding that comes from working in the field and the conceptual understanding that comes from study of the problem domain. The two understandings complement each other and the successful engineer needs both.

You may not like the concept's model or terminology and you may think people give it undue mental weight, but those are not excuses to eschew the concept or to assume that knowledge of a broader concept somehow obviates the necessity to know the more specific one.

George ============================================= Send real email to GNEUNER2 at COMCAST o NET

Would not the start and end of a transaction also be considered an event pair. I would not say that managing transaction streams is that much of a complecxity problem. Of course, you will realise, that my experience revolves around the end-effector end of machine control systems. All end efectors are monitored to prove the accomplishment of individual tasks and I usually run several autonomous threads on each processor dealing with specific aspects of that modules operation (Comms, Machine Motion, Integrity Monitoring etc).

I view "Real Time" as one of those terms that has been ill-defined, over used in the wrong context too many times and, in some cases, missing a much more important risk factor than not performing by a deadline. It is such that I tend to ignore the "Realk Time" aspect in my developments and concentrate on whole system risk factors and mitigation ploicies that will mean the whole process is still protected well enough despite any individual failures of the system.

....and at least one of those in your list implies that system pre-knowledge of the process behaviour is more important than the time factors. Prevention is always better than the cure once things are looking like they are going wrong.

The art of system architecture is in controlling the complexity of the system structure and keeping sub-systems simple enough to keep such factors well under control.

More importantly the engineer must understand the process that he is expected to develop controls for. Unless you understand the dynamics and risk points in the process you are lacking in the information required to do a decent design job.

Letting all aspects into the melting pot actually leads you to making some different choices that tend to assist in simplifiying the system. Looking for system pre-knowledge opportunities will often lead to being able to use a slower (most likely cheaper) processor than other system engineers would normally choose.

I am of the school that says you need to understand both the conceptual and the actuality of the field that you are working in. That often means not only looking at the specs but also talking to the plant operating personnel to get their viewpoints on how they would prefer to interact with the system. The most successful systems engineers are as much a social engineer as they are hardware/software designers. The systems engineer brief is a very wide arena.

It is not a matter of not liking the concept. It is the realisation from over thirty years of experience dealing with other (non-system engineering types) who have mis-used and abused the term for so long, corrupted the concept and let such mis-conceptions that they have coplour the way they write their specificsation documents (but that is probably worthy of another thread than this).

If you want to promote "Real Time" as a concept then you have to fix that sort of long term abuse by really nailing down the definition and then geting it well agreed. For me the timeliness of operation of my systems will continue to be viewed from the event perspective and performance factors revolving around the event processing of the system and how it applies to the process/equipment that it is controlling.

... snip ...

No, that is another concept entirely in the realm of concurrent processing. That is called the indefinite postponement problem. Still another area is that of fairness. These all have to do with what process is selected to run next, i.e. the scheduler.

also commonly referred to as a 'patch' / no doubt named after the thorny ones with the berries. the poisonous ones of course.

There is nothing magic about transactions - a transaction is just a series of discrete events related by shared state. But, unlike an event, the transaction is, by definition, durational and lends easily to modeling timed and time related processes. My point is simply that, if you start from discrete events, by the time you've enumerated the events, defined their relationships, and defined the state required to relate them ... you've reinvented transactions.

I do a lot of sensor, QA and QC applications that frequently have tons of I/O and multiple compute operations going on simultaneously. I find it much easier to model such systems as sets of transactions rather than as a myriad of time related events.

Again I stress "model" the system ... ie. design. Implementation invariably deals directly with discrete events and the state that relates them - however, I have found that starting from the transaction model produces simpler designs because it more clearly identifies operations that can be elided, combined, pipelined, etc. than does a model involving many sets of inter-related events.

The fact that many people misuse the term is not evidence that it is "ill defined". According to the Oxford Dictionary the English language has some 800,000 words in the language proper and over 1.1 million words in slang usage. How many do you know? Do you think the words you don't know are not defined? Do you think it more likely that the words people misuse are ill defined or that the people who misuse words are poorly educated?

I agree that the term "real time" is both over used and abused in context. That's a matter for better education.

I agree that this is unacceptable. I question, however, whether this is because of some particular "RT mindset" or can be explained more generally by the lack of ability to think at different abstraction levels. Over the years I have had to work with many people who saw the trees but not the forest ... these are exactly the people who get stuck on the obvious and can't get past it without help.

I accept that because you are clearly aware of the problem and are making certain it is dealt with - albiet in a different way than I would. I personally like to see risk domains enumerated separately, but this is a personal preference - so long as the issues are addressed adequately I am happy.

I wasn't trying to be funny. My point is that RT systems are more than the sum of their time dependent code and while time is an important component of their operation, time is almost never what they are about.

I think we're in violent agreement here. We are both advocating having domain knowledge, the ability to think at multiple abstraction levels and to view the problem from many angles. I'm just advocating a more diciplinary approach and you seem to prefer a more holistic one. We both are trying to achieve the same end.

Only 20 years here so I concede that you have more reason to be annoyed and have a strongly held opinion.

I have a policy of correcting people when they are wrong. If I know the person fairly well, I may just stop and correct them on the spot. Otherwise, I typically point out some subtle thing they overlooked and try to work an explanation of the concept and proper terminology involved into the ensuing discussion.

Both approaches have been known to work on occasion 8-)

Education is the only answer to that.

I think there is already pretty good agreement on what RT means - at least in the theoretical sense - and it's been documented and discussed fairly well in a number of system and software engineering text books. The problem, as I see it, is that many people who work in the field have never read any of these books.

George ============================================= Send real email to GNEUNER2 at COMCAST o NET