...
What is Modeling?
For this discussion, we will define a model as an organized, formal method of representing a system or component of a system. By a formal method, we mean that the method has a defined set of semantics - a language. The "language" of the modeling system consists of a syntax: that is, a strict set of rules as to what constructs are allowed and what constructs are illegal in the language. The model language must be unambiguous so anyone that understands the syntax understands exactly what the model is portraying. Thus, the syntax defines a strict relationship among the elements of the language.
A useful model conveys all the information necessary to evaluate a design. It has all of the necessary parts (constructs) to define everything about the system, including everything external to the system that affects the system in any way. The formal term for an external "thing" that interacts with the system being modeled is "actor". Actors are not necessarily people, and usually aren't. A sensor that provides information to the system is an actor. A motor that the system activates is an actor. A panel the system uses to display information is an actor. The person who pushes a switch is an actor, as is the switch the person pushes. The rule is that an actor is external to the system.
A model has to be capable of representing all possible conditions of the system being modeled. If it does not, the model is only valid for those conditions covered by the model. Consider that for a moment. What good is a model that only tells us what the system will do in a few specific circumstances? It is one of the laws of nature and engineering that a user will find and exercise every one of the possible (and three impossible) conditions a system can be placed into.
There is little in this world that is more useless than a bad model. I have had to fix many systems that were designed around a faulty model. I know the attitude "any model is better than no model" is a sure path to failure. You can design a system exactly to specification, but if the specification is based on a faulty model, the system will not work. It will do so exactly to spec!
A model is supposed to be a means of assessing the completeness of a design. It has to cover all possible conditions to do so. It therefore has to model every possible external influence and interface as well as all its internal workings. One is useless without the other. You can't model a system if you don't know all the requirements and constraints of the system. As stated in the last paragraph, you have to accurately model the requirements of the system to make the finished system work. So what are some typical constraints?
Since we are dealing with embedded systems, timing is usually a major constraint. While most systems are not "hard" real-time systems, at least part of most systems is some flavor of real-time. Hard real-time systems are defined as systems that must meet all timing constraints or the system fails. Late data is bad data, period. A missed timing requirement is a fatal error. Soft real-time systems are defined as systems that must meet all timing constraints on the average. Events (such as data arrival) must meet an average latency (lateness) requirement, but it is not an error if some events take longer, as long as all events are serviced within the average requirement. Some embedded systems have no real-time requirements. The processor in your Mk IV Grits Maker and Potato Peeler only has to respond when you push the start button or the end button. It does not matter if it takes it 1ms or 500ms to do so.
Real-time systems usually involve some kind of synchronous events. Synchronous events are those that have a defined and finite period, duration and skew. The period of an event is a measure of how often it occurs. Perhaps you have to service a watchdog timer every 100ms. Duration is a measure of how long an event lasts. If that timing pulse is only 3ns wide, you have a lot tighter constraint than if it only clears when you manually reset it. Skew is a measure of how much the event time can vary. If your 100ms timer can be off by 10ms, you have to be careful to take that into account when you design the circuitry that depends on that timer. What works at 100ms may not work at either 90ms or 110ms if it isn't designed properly.
Another, far more common event is the asynchronous event. This type of event is one that can occur at any time. Such events may represent a key press, a switch closure, a serial data word or any other event that is not clocked by a system clock. Some of the attributes of asynchronous events are the minimum and maximum time between events. Asynchronous events also have an attribute called "burtsiness": how many events can occur within what time span. If you don't know these constraints, you can't possibly design a system that will correctly handle them.
A hidden but equally critical constraint is resource usage. How much memory does the system have? How much buffering do you have to use to make sure all asynchronous events are stored for processing at the maximum burst rate and duration? How many events do you have to store to have enough information to process the data? Remember, you may be working with a bit stream that takes several hundred events to pass enough information to make a complete event! Consider a 2.5 Gbps (2.5 billion bits per second) data stream that has one byte (8 bits) of data embedded in each 17kbyte frame. This is typical of processing a voice/data channel in an OC-48 SONET environment.
We will talk more about modeling and get into details of using modeling to design a system in the next tip installation. Check back as I will try to put out one of these every week, work permitting.
Pat