Table of Content  Branch Up  

System Architecture

The GP LOGIC system relies on a centralized Linux host running the GP LOGIC Master Software. This computer communicates with different units by the mean of a 3 wires RS-485 bus. One of these equipment is a Parallel Interface Unit (PI) that implements the GPIO ports. Up to 14 devices can be connected to such a bus; this limit can be overcome by providing more buses fed by separate serial ports.

The Linux host computer can also be virtual if a device server equipment is used instead of computer physical serial ports. It is also possible to have two Linux hosts in a automatic fail over arrangement.

PI units can be of different sizes. Currently under development is the GPP-112 unit providing 12 GPIOs. Each port can be configured as either a GPI or a GPO. A suitable configuration is 8/4 meaning eight GPIs and 4 GPOs.

Each unit has a 4-bits address number set by jumpers in the unit hardware; this address must be unique within the same bus. Addresses 0 and 15 are reserved for special purposes.

A given GPO in any unit can be activated or deactivated based on a boolean combination of any given set of GPIs from any unit. This logic is set by the user in the Linux host as part of the system configuration in the form of "rules" written in plain text files.

GP LOGIC allows the existence of separate systems, isolated from each other in terms of GPIO logic. "Isolated" means that no GPO in one system needs to be activated based on the state of GPIs from other systems. This implies that "rules" in one system do not contain GPIs or GPOs from another system.

The configuration associated to a given system is called application. Rules and other configuration parameters recide in a plain-text file called application spec file (spec-file for short).

The Master Software creates separate processes for different applications to allow for concurrent execution. Since different applications run in separate processes, it is safe to suspend or restart an aplication (process) without impacting others. It is also possible to add new applications to the overal system without disturbing the execution of those currently installed, possibly taking care of crytical tasks.

If the application utilizes 14 units or less, a single RS-485 bus fed by a single serial bus will suffice. If more than 14 units are required, separated buses fed from separate ports can be installed, as long as no other application makes use of those buses.

The communication on the RS-485 bus is always initiated by the master (Linux host running the Master Software). In order for the master to obtain status from PI units, a round cycle of query commands needs to be issued on the bus. For each step in the cycle, the master sends the command to an (addressed) unit, then waits for the response before sending a command to the next unit.

In general, commands are not sent as they are produced. Instead, they are queued and sent at regular time intervals over the bus.

Two commands are noticeable:

   GET STATUS: Get GPI and Alarm status from addressed unit.
   GET ADDR  : Broadcast command to which each unit responses with its address.
               This command serves auto-discovering purposes.

GET ADDR is particularly interesting. Since it is a broadcast command, all units will decode it simultaneously; however, units can not be allowed to respond at once because that would cause collisions in the bus. The implemented solution is that each unit delay the response by 1 ms multiplied by its address, minus 1. Thus unit with address 1 will respond immediately, unit 2 will delay 1 ms, unit 3 will delay 2 ms and so on.

With 14 units in the bus (maximum permitted) it will take 14 ms for all units to respond. This figure imposes a lower limit to the query cycle step time. The implemented value is 20 ms. GET STATUS commands (and any other, by the matter) is sent every 20 ms. The complete cycle will take 280 ms in the worst case (14 units).

At 19200 baud, a GET STATUS command plus the response will take 3.25 ms in the worst case, so the tolerance to communication and processing delays is more than adequate.

NOTA:
-----
Otra posibilidad es hacer el query cycle "normal" de 5 ms, y solo hacerlo de 20 ms si el comando lanzado es GET ADDR. Se puede incluso renunciar a la idea de un query cycle fijo y dejar que cada comando tenga su propio "tiempo de espera" para la respuesta el cual se puede hasta calcular at run-time (en lugar de fijarlo por disenno).