What is ioStudio?
ioStudio is the result of a research project that was started in 2010. The objective of the project was to establish a framework of hardware and software components that would be optimal for implementation of future maritime control systems. The background of the development was experience from R&D work done for Simrad products (autopilots, instruments, sensors and chart systems) and Kongsberg Defence & Aerospace Dynamic Systems.
A maritime control system can become unnecessarily complex and platform dependent. The starting point for ioStudio was therefore to evaluate using technologies that would be platform independent and consist of re-usable components. The components must also be compatible with established standards for maritime control systems.
For HW components, there are embedded solutions and off-the-shelf solutions. Off-the-shelf solutions should be chosen, if possible. Sometimes off-the-shelf solutions do not comply with requirements for the system, though. There may not be enough space or power for the component. The environmental requirements or real-time requirements may also be too specific or harsh.
A software component therefore needs to be deployable both on embedded and off-the-shelf devices to enable the control system engineer to choose the optimal solution.
There has been a continuous development of SW programming languages used in maritime control systems in the last 30 years. During these years, the C++ language has evolved from assembly coding, the function-oriented C language and now an object-oriented language. Control system developers must therefore today also be capable of designing object-oriented software.
C++ is the programming language that can be used on several different platforms. This language was therefore chosen to be the backbone of ioStudio. All SW implemented, including the interrupt service routine and board support, is object-oriented C++. The ioStudio research project also found a way to move this software between different platforms and only changing the board support package. 95% of all the software in the system should be movable.
A maritime control system also needs a software and hardware front-end implementing an operator’s station. The development of front-end applications has been evolving from hardware buttons, LED’s, LCD displays, color displays, desktops, touch panels to web and mobile phones. The hardware button may still be the optimal user experience, even though glossy displays are the ones dominating sales exhibitions.
The OpenBridge project has also been addressing the huge variety there is in operator’s applications. In bigger systems there are more applications, and each application has its own logic. This variety is confusing and is a source of operational danger.
Cyber security issues also need to be addressed when building a control station for maritime applications. The development within application development is to isolate applications in packages. Computer resources required outside the package need to be approved by the user. Web applications can access computer resources also, but there are greater limitations compared with installed applications. Especially local disk access can be very useful to increase reliability and decrease network dependencies.
The primary type of application useful for a maritime control system seems therefore to be the one that is locally installed compared with web applications that require an initial download to a client. Web applications may be useful for servicing control computers, though. Whether the application is installed on a Linux or Windows computer may depend on the type of application to be installed.
The ioStudio research project has therefore found a solution for implementing front-end applications that are platform independent. One application project can be deployed both as a Linux/Windows/Android application or as a web assembly. The application is OpenBridge compatible.
Having both the backend and frontend of the system platform independent gives great flexibility when the system is going to be adapted to the need of the user. Too many systems require that the user needs to adapt to the requirements of the system and not the opposite. This can change if the system is built with software and hardware components giving the control system engineer possibilities to use components fitting the purpose.
The engineer also needs a tool to build the system in. This tool needs to be able to connect inputs and outputs and to simulate the operation of the control system. This is implemented as an ioStudio Basic application running on Windows. It’s important that the projects loaded and saved by this tool are adaptable to different types of systems. The OPC UA standard has been developed to be the backbone of different types of control systems. This standard defines an object-oriented way of building up an address space and an information model for a system. ioStudio Basic projects is not a copy of the OPC UA way of modelling a system, but it should be possible to export and import between ioStudio Basic projects and OPC UA models. It should also be possible to configure and simulate NMEA, IEC 61162-450, Modbus and CANopen ports. Other standards of interest for export and import is PLCopen (input/output programming), Module Type Package (MTP, control system topology) and Functional Mock-up Interface (FMI, control system simulation).
