Display value

The value is captured by the Class B/C system and sent to the Class A GUI system.
The SOUP used for transfer of the value between the systems (OS kernel, libraries) and for the output of the grapfical information (graphical hardware drivers, libraries and the high level graphical widget libraries).

What is the reason the wrong value displayed:
1. The value is corrupted during the transport or during the processing and wrong value displayed to user. This is possible:
1.1. Fully wrong (out of range) value is displayed
1.2. Wrong in range value is displayed.
1.3. The graphical output is not readeable
1.4. Last value replayed: due to HW/SW error in one of the components the same information received mulztiple time versus new information (for example error in the Tx or Rx of the low level driver, ...).
2. The value is not received (lost) during transport and the obsolete value is displayed to user
3. Wrong value is received (routed to the wrong destination) and wrong value displayed to user
4. Processing of the value delayed. Value delayed during the transport or during the processing in the Class A SW. Value displaeed with significant delay. De-synchronization with other related values possible.
5. The value received too often and leads to the overload of the Class A component. The displayed value is not updated or updated with significant delay. This is possible due to error in the SOUP.

The best solution is "Observe the display by the camera and control the values displayed by security processor".
Unfortutionally this solution can be used only rarely.

The solution proposed below is modular, increasing the strength from the weakest possible to the strongest one.

1: Repepetive transmission

The Class B/C components shall send the information to the Class A component according to the following rules:
1. New information received or capured.
2. Periodic transmission of the last received/captured value.
The transmission period must be selected in such a way that the effect of the individual incorrect displayed value on the essential performance of the system is omitted.
The best effect achieved if the GUI performs re-drawing of the value displaed each time new value received.

2: Sequence numbers

The information originator (Class B/C SW) shall include the free running end-to-end sequence number in each information item sent. The GUI SW shall accept the new information received only if the sequence number changed.

3: Identificator of origin

The information originator (Class B/C SW) shall include the system wide unique end-to-end identificator of origin in each information item sent. The GUI SW shall accept the new information received only if the expected information of origin received.

4: CRC

The information originator (Class B/C SW) shall include the end-to-end CRC in each information item sent. The GUI SW shall accept the new information received only if the received and the calculated CRC value math.

5: Stateless GUI

GUI SW shall be stateless. In case GUI SW restarted the correct function shall be restored automatically due to periodic transmission of the incoming information.

6: Feedback

This is not possible to leave the GUI Class A while implementing the check listed above (sequence numbers, indentificatior or origin check and the CRC checks).
One additional controlling instance necessary to ensure the required functions are performed by GUI SW and by SOUP.
For this reason one feedback shall be sent to controlling istance. The controlling instance may be one security processor or the originator of the information sent to GUI (Class B/C SW).
This feedbabck is periodic and allows conclusion about the GUI SW function. If no feedback or if not correct feedback received for specified amount oif time the action shall be taken: Restart GUI, inform user and activate one alternative GUI.
The system reaction time (fedback period + time until problem detected + GUI restart time) must be selected in such a way that the effect of the single GUI restart on the essential performance of the system is omitted.

The feedback shall be sent after the GUI elemt was updated. The feedback context depends on the system capabilities and on the sequirity/integrity level required. Possible options:
1. Periodically sent the informatiin element with bit changed (multiple bits allow feednback for multiple GUI elements)
2. Each time (or each N-th time) GUI element updated send feedback message with: identification of origin updated, last free running sequence number received, GUI element value. The code element vale is "coded back": input -convert-> required by GUI element format -convert back-> feedback.
3. Each time (or each N-th time) GUI element updated send feedback message with: identification of origin updated, last free running sequence number received, captured graphical data displayed.

The transmission of the reqd-out graphical data is bery resources extensive and is not always possible. For this reason the option 2 (send the value back) is used for all GUI elements except one, which uses option 3 (send graphical data).
Moreover element used with option 3 is one invidible 4 (or more) pixel GUI element, For this reason the "read-back" is very simple and does not requires significant resources: it is at most 4 x 32 nbit values.
This is often implemented as direct command which allows the Class B/C SW to control (change) read back single pixel value any where on the display.
This allows implementation of the walking invcisoible patterns allowing to cintrol the SOUT and the Class A GUI SW functionality.