Remote Operation of Oberon System Instrumentation
Synopsis. Remote operation and remote control of instruments is one of the primary motivations for the Risk Project. In this section I will outline how the Oberon System will make this task easier to achieve.
Motivation. In our field of Nuclear Electronics, it is natural that our instruments are deployed in high radiation areas which are better avoided by the human operators. The instruments need be controlled from a distance, preferably over Ethernet. Other links are often used too, like wireless, a serial connection, or some proprietary link. At the first glance, Linux single board computers would be ideal for such tasks. And indeed, we developed advanced nuclear instruments with embedded Linux. However, Linux is both resource and development - hungry. Simple control tasks would be better served with a system simpler than Linux.
Background information. The original workstation Oberon System supported networking with AppleTalk which is now obsolete. When this OS was re-released by Professor Niklaus Wirth and Paul Reed in 2013, the authors provided a modern wireless network over the 2.4 GHz band using an Arduino NRF24L01 module. In 2020 the module is still readily available from multiple vendors. The Ethernet was not supported in that release due to limitations of the Spartan-3 Starter Kit used by the authors.
Since Ethernet would be "good to have", we added Wiznet chips to our Risk boards. These chips encapsulate the TCP/IP in silicon, avoiding the mundane details of the TCP/IP implementation. RiskZero provides the SPI-to-Ethernet converter W5500, while RiskFive provides both W5500 and a higher performance W5300. Additionally, RiskFive provides a gigabit PHY connected to the FPGA with the SGMII interface, intended for efficient streaming of data with low level UDP protocol, to be developed later.
Symmetric versus non-symmetric data transfer. In our instrumentation the data transfers to and from the instrument will occur at unequal rates. Since nuclear electronics may not be familiar to the reader, we will consider a more familiar example of a remote digital camera. Before taking the photograph, the camera needs to be prepared for the shot. The setup commands will tell the camera a few details such as the exposure time, the image definition, and a few others. The setup comprises a small amount of data. A large amount of data is acquired during the shot and usually saved to an SD card. (It may also simply stay in the volatile memory.) Large amount of data is then transferred to the host computer.
The setup link versus the readout link. The asymmetry between the setup link and the readout link is depicted in the figure below. The setup link can be slow. It needs to use a simple protocol to avoid difficulties in software development. The readout link has to be efficient. Both links can operate over the same physical medium, but they do not have to do so. Technically it is possible to control the instrument over a serial link, and read it out over Ethernet. Using the same physical link in both direction is preferred, but it is not imposed by any firm rule.
Oberon Command Syntax. The Oberon Command Syntax described below is very well suited for receiving the control messages by the Oberon System. The syntax makes it also easy to form the commands at the sending end of the control link.
Resistance to hacking. Oberon Command Syntax will make the instrument highly resistant to hijacking by a remote hacker.
Summary. Many (though not all) instruments will benefit from the asymmetric protocol, where the control path is providing convenience, while the return path emphasizes efficiency. The built-in Oberon Command Syntax will make it easy to develop distributed control of instruments running Oberon System. The protocol will make the instruments highly resistant to remote hacking.
Oberon Command Syntax comprises plain text commands of the form Module.Procedure parameters, where the "parameters" are ASCII items of any nature. The command can be either entered with the Oberon Workstation GUI, or sent to the instrument over any suitable link. The GUI interpreter is built into the Oberon System. The remote command receiver needs to be developed. A sequence of commands to snap a photo with a (hypothetical) remote camera could look as follows.
Shutter.SetSpeed 0.01
Aperture.Set 2.8
Control.Snap
Control.Save
Control.SendData
The above looks like a description of a command line, but there are important differences. The command is not merely executed. The command loader checks whether the Module is already present in the memory. If not, then it is loaded from disk. The loader then tries to find the Procedure among the Module's entry points. If it is found then it is executed. The Procedure is responsible for reading the parameters. Their interpretation is left to the programmer. After the Procedure ends, the Module remains loaded in the memory, where it will be found upon the next command. The time consuming loading from disk is performed only once, greatly enhancing the performance of the embedded system.
We will use the above mechanism to implement the remote command interpreter by reusing the existing one. (Following the rule that the most efficient method of software development is no development.) The remote command interpreter will receive the incoming ASCII string and pass it to the official command loader after comparing it against the White List of permitted modules. The White List will implement the defense against hacking. Any module, which can compromise the system integrity (like for example modifying the disk), will be excluded from the White List. The permitted modules will deal with the setup, data acquisition, and data retrieval. Remote compilation of new modules will not be permitted.
The remotely controlled Oberon instrument is sketched below. The hypothetical setup commands are verified against the White List of permitted modules. The acquired data is returned over the same link or a separate link, either in the binary format or ASCII. The details of the implementation will be elaborated in separate documents.