North-Holland

Microprocessing and Microprogramming 16 (1985) 249-254 249

Event Driven Real-Time Operating System in Intelligent Network Communicator

Jaro Berce

Iskra-A v~omatika, Mlinska pot 20, 61231 L/ubljana, Yugoslavia

Present paper discusses a scan of common features whenever applying a communication microcomputer, what is usually called an intelligent network communicator (INC) in the data communication networks (DCN). Real-time operating system (RT-OS) for INC is reviewed as well. It terminates with some suggestions that can be applied in actual procedurs and proposes few improvements to be considered.

i. INTRODUCTION

When two or more communication systems are connected together there is a need for communication system to do an "intelligent link". Many functions that must be performed concurrently within a short response time are compulsory required as a timing-critical application problems are normaly present. Microprocessors are becoming more sophisticated and more powerfull so they are frequently applied to execute the needed communication work.

Basic INC requirements to function as assigned to it are:

- to communicate with remote devices with an aim to secure a credit to acquired real-time data and to issue supervisiory control commands,

- in maintaining whatsoever applicable data base,

- in providing communication services for overall data links to various devices,

- in securing periodical updated real- time information required, if there exists the reserve system (as hot- stand-by) ,

- and to be kept responsible for

settling and maintaining control of DCN system configuration.

In most applications INC is used as a front-end processor (FEP) to link devices to the host system, discharging it of communication jobs (figure i.i). Therefore INC should provide safe-

guarded and trusty bidirectional data communication facilities among various real-time elements and must sustain the bidirectional structure and the functionality of DCN. It has to be able to uphold all spontaneous or requested data that exist and/or are demanded by communication protocol.

INC hardware requirements referring on applied channels should be of any combination whatever synchronous, asynchronous as well as full/half duplex or other demands depending of channel type and must be supported by appropriate software.

All extensions over the existing $W and HW, or when new devices are required to be connected, have to be sheer and not time-consuming. It is advantageus that, when DCN has to be a completely autonomous system qualified of being installed and operated independently of any associated devices, to sustain the requirements that have to be upheld with proper real-time operating system and its supporting programs (such as diagnostics, monitor etc.) and with INC application part (figure 1.2.).

2. REAL-TIME OPERATING SYSTEM COMMUNICATION MICROCOMPUTER

FOR

RT-OS is a microcomputer internal supervisior and executive software which allows INC to support all system functions in a real-time. It thus exploits the architecture features of INC hardware and thoroughly takes advantages of an avaible instruction set. For a selected and a described INC

250 J. Berce ~Event-Driven RT.OS in INC

REMOTE DEVICES

0

SYSTEM

I I

Figure 1.1.: Front-end-processor in data communication network

the RT-OS shall be entirely memory resident and should provide all required real-time services in a memory. It is obliged to manage all sequences and/or tasks that are exe- cuted in the microcomputer through initialisation, extending of execution, and ending with a sequence/task termination.

Fundamental concern for RT-OS system is to produce the correct job within the alloted time. Therefore the code used to service an event has to be executed within predefined time /I/.

Since events may occour at unpredictable time and order, real-time system must be able to respond to such events asynchronously what effects scheduling events /2/.

RT-OS therefore provides a multi- sequencial environment with all real- time succession continuously resident in the memory, competing with each other to be handled within accurated common resurces of the CPU. It supervises states of sequellae or parts of it, by variety of means due to the orders or the events (normal start, execution or termination cause normal exit from CPU, but in abnormal circumstances special sequences or routines shall be provided). Resource assignments are determined and adjustable by RT-OS at its run-time, depending on the control statements. RT-OS enables device I/O independent services to routines in execution, and furnishes dynamic run time assignment for logical indentification to physical device. Queues are maintained on a per device or per event basis so that requests are honored in order of the requested priority. A protecting system against unexpected or inadventent access, event, or happening should be provided by RT-OS.

3. RT-OS FOR INC

An RT-OS capable to support multiple real-time events /3/ (that depend of communication protocols) which are represented by special sequences of routines (with corresponding data) must fit the following nucleous of functions

timing control over the operation,

- interrupt handler,

- dynamic control on execution,

- starting and (re)scheduling successions according to the events or the states,

- intersequencial synhronisation.

communication and

Therefore corresponding parts of RT-OS can be described by (figure 3.1.) :

- scheduler of sequences depending on events (bearing on a strong association with a required application),

- "time-out" system for a time control of an execution (OS and its application part),

- diagnostic and control system at occurrences of irregularities (unconsistency, bus error, looping etc.),

- interrupt handler and drivers (supporting protocols on channel types),

- attendant part (queueing of messages,

occupaying/releasing control buffers or etc.).

3.1. Scheduler

Base on which derivation of OS is set up as a real-time is the clock period in which sequences according to

communication status buffers

J. Berce ~Event-Driven RT-OS in INC 251

Figure 1.2.: SW structure of INC

occurrences of events are initiated, and may be carried on with execution or can be terminated.

The clock period is primary divided in two elementary levels and must fit with real-time requests /4/. The initial term of it is shared into use of RT-OS settings and into critical jobs that shall not be disturbed by unexpected incidents (interrupts), therefore this fragment must represent a very short segment of a clock interval.

High priority events, which are also part of the first level, are treated just after this section, but can be interrupted by external occurrences.

Second fundamental portion of the clock period is so called "base level", on which most of the remaining time is exhausted. At the begining of this intermittent time interrupted or broken tasks are managed, and after that "low priority" jobs are handled out (figure 3.2.).

3.1.1. Occurence of event

If incidental event occours, its priority and nature determined in advance figures out, how it should be processed and consequently placed into a suitable queue. Data from a DCN device cause an interrupt at INC physical device. First the status of device is treated. Then if it is correct a logical indentificator (status buffer - SB) which shall contains states of a call and shall hold appropriate communication control buffer (CCB) shall be assigned to this device. Every message composed of events has to have its status-states and/or other important facts bound up on it and therefore must have be assigned a buffer for temporary storing (because a message can be composed of nonseparate blocks, or can have control data etc.) before translating into correct device. Therefore a CCB is allocated. After all prescriptions are executed a result is set up to the special predefined sequelae (i.e. state transition diagram) and from its state and corresponding data an event could be placed into predefined queue or/and new data could be expected.

Event shall be taken from queue through schedular and transformed form to adequate sequence that is composed of routines which must be executed in "proper" manner depending on "routine- data" and deciding appropriate execution steps.

3.2. Time control

Section by which a time control and/or decisions are made for "proper" execution is "time-out" (T/O) system. It manages the real-time control upon an appropriate execution of events with their corresponding sequences. System is so designed that for starting and stopping time control, special locations in CCB are used. When starting T/O, type, event and identifying pointer to CCB are saved in "time relative" shiffting location at T/O buffer. Every determined clock period special routines updates counter to these locations and treat theirs contents. With starting/stopping T/O system manages as well if started time control has not been stoped (expiring) therefore special treatement routines shall be switched on time control on CCB. So it is possible to control time execution upon a call through T/O system. Occurence of events can awake sequences or other events just at a

/

252 J. Berce ~Event-Driven RT-OS in INC

Figure 5.1.: Parts of RT - OS

predefined time. T/O system is able to manage the situation even when event could not be fully initialised, proceeded, or stoped by generating special/abnormal event and must take care over the execution

3.3. Execution control

Diagnostic and control modules are

derided into system and application parts.

DoIo

I

Enabled Interrupts

HIGH PRIORITY

LEVEL BASE LEVEL

Clock period

Figure 3.2.: Sections of clock period

J. Berce ~Event-Driven RT-OS in INC 253

System portion has obligation to govern over all HW and SW components (through spurious interrupts or looping in routine(s), illegal instruction or damage in HW system are some of happe- nings which must be of significant concern for this part). Its use is of prime importancy when application part is in a period of implementation and testing. In normal occasion it should not be awaked, but if it is, his job is in restarting or pursueing the system execution and to note all significant data of tha incident.

Application module is regulated by requirements.

designed and communication

system especialy in the field of man/machine communication (build-in monitor for direct work with INC, or in a mass storage part etc.) it could be used in many other fields of communication, because types of protocols are build-in in application part and are easily updated if necessary. RT-OS is independent on number of channels (the only limit is at CPU capasity) and installed proto- cols because these boths are avaible as options and are not affecting RT-OS.

5. LITERATURE

3.4. Interrupt services

Drivers are services for interrupts from outer world and are writen on communication protocols desires. They are short services routines (because of time postulation) which must treat periferal resources according to their desires and data to be handled so they are not always a part of RT-OS by meaning.

3.5. Attendant part

To support queueing, dynamic assignements/releasing logical identifiers to physical devices or dynamic assignements of CCB and other important accompanying jobs for appropriate work, there is a supporting attendant Dart with tasks performed according to the need. Also some dis- tribution tasks for special use executions are performed in this part and in all application definable routines (with extended use) can be built in when are not significant for one application alone.

4. SUMMARY

/I/ V.D.Gligor and G.L.Luckenbaugh : An assessment of real-time requirements for programming environments and languages, CH1941-4/83/0000/0003501.00 1983 IEEE, p. 3-19;

/2/ F.Eser and F.Schmidtke : process communication within a distributed multimicrocomputer system, Microprocessors and microsystems vol 5 no 4 May 1981, p. 149-152;

/3/ H.N.Koivo and A.Peltomaa : Microcomputer real-time multi-tasking operating systems in control applications, Computers in industry 5 1984, p.51-39;

/4/ F.Linden and I.Wilson : Real-time executives for mocroprocessors, Microprocessors and microsystems vol 4 no 6 July/August 1980, p. 211-218:

/5/ J.McGrath and P.Strzelecki : Functional architecture, systems International January 1982, p. 51-53;

/6/ D.Bernhardt and E.Schmitter : design and implementation of fault- tolerant multi-microcomputer systems, Microprocessors and microsystems vol 5 no 4 May 1981, p. 153-156;

/7/ J.Berce : Executives for real-time multiprocessors systems ,Informatica 3/85 UDK:681.3.012, p. 33-38.

Basic principles described in the article can be alternated according to the ezigeucies on which RT-OS can be build. Described RT-OS was made and installed in a DCN system where remotes devices are coupled through INC to the host system. With some changes in RT-OS