The Model Railway
Software
libRailControl
Constants/Functions
Process Comm.

Process Communication Framework

A control program has basically to decide wether a train may enter a certain block or not. There are generally two ways of implementing the mechanisms for meeting these decisions:

• There's one process for all block sections.
• There's a process for each block section.

Students participating in the lab courses have to follow the second way. Therefor the files "/home/railway/inc/process.h" and "/home/railway/template/main.c" are supplied. In "main.c", for each block section there's a frame yet free of code, that will be compiled to the corresponding process. Each process created for a block section is only allowed to request the following informations and modify the following settings via library calls:

• Get the readings of both velocity meters (if present).
• Get and modify the speed value of this block.
• Get and modify the operation direction within this block.
• Get and modify the point position of all points within this block (if present).
• Get and modify the realy position (only OCIC_LN_2 and ICOC_LN_2).
• Get and modify the set signal position of all signals protecting the block (if present).
• Get the signal position of all signals placed aside the block (if present).

For getting informations concerning other block sections, a process has to send a request to the appropriate process. The other way round, a process has to answer all requests sent to him again by sending a message.

To free the application programmer from the need of implementing the message passing facilities, they are provided with the library. The function prototypes and constants are located in "/home/railway/inc/process.h" and "/home/railway/template/pstate.h".

The block section processes are only being regarded conceptually as processes. In fact, they are still part of the main()-routine where they are being invoked in a round robin fashion. Each process runs as long as it terminates itselfs, so the application programmer has to provide a cooperative process behaviour.

By using this process communication framework, students are introduced to the problem of creating a program in a "distibuted memory system" environment. Consequently, they should get a view for at least some sort of problems which come up when an application runs distributed, e.g. over a network (LAN, Internet etc.) or on a multi-processor system.