Voice Communication Systems for Mission Control
Openvocs is a platform for Voice Communication Systems for Mission Control. Openvocs is a new kind of Intercom Systems used for Space Communications in Mission Control Room environments. Openvocs offers a customizable Webbased Client interface for system interaction and media distribution and a dedicated backend system for Authorisation and Authentication as well as media mixing. As Client a standard Webbrowser may be used. No installation of additional software is required. The Client is based on HTML5, CSS and JavaScript without usage of additional Frameworks. The backend is written in C with a minimum of external dependencies. The whole system is build with maintanability and simplicity in mind.
This work is licensed under CC BY 4.0
What are Voice Communication Systems (VoCS) for Mission Control?
Voice Communications for Mission Control enable communications within (Space) Operation Control Center environments. VoCS is the terminology for these kind of systems. A VoCS streamlines communications within different channels called Voiceloops. These systems support Multiparty Multiconferencing capabilitites. A VoCS system in the common way is a dedicated Turn-Key platform. Different control centers are using own dedicated VoCS instances to communicate internally. External communication is done via Voiceloop sharing over different kinds of media. These media may be analogue couplings, T1 based interfaces or in some newer sceanrios IP based interfaces.
Each position within the Control Center has a dedicated Voiceloop. Some Voiceloops are spread over different positions, some are fixed to a position.
An occupied position is classified as a role. The whole system needs to be able to support Role based Access Control. Communication is done from one Role to some other Role e.g. a Flighdirector is talking to some subsystem Engineer.
The first aspect making VoCS systems special is Multiparty Multiconferencing. The ability to listen within several Voiceloops at the same time.
Due to the formal communications a next aspect, which is special, is Push To Talk (PTT). PTT is used to have an additional active interaction before any Voice is transmitted.
The last speciallity is the interfacing with the system. VoCS distinguisches between active and passive communication. This is called Monitor enabled, which equals listen and Talk enabled. With PTT and the off state we have 4 different paricipation states, None, Monitoring, Talk enabled and Talking.
VoCS system are not definied in terms of interconnectivity between different vendors. Venders are rare, only a small group of manufactorers offers VoCS systems at all. Each vendor has it's own architecture and solution to provide VoCS capabilities. Nonetheless all comes down to the 2 main capabilities of VoCS, Multiparty Multiconferencing and Role based Access Control.
Voice Communication Systems for Mission Control redefined
The idea of openvocs is pretty simple. Define some reference architecture and environment for Mission Control Room Voice Communications. Upto now noone defined a reference system for VoCS. Some definitions can be found in the CCSDS Green Book but they a lacking a reference architecture and protocol definitions for interoperabillity within the systems, whereas external protocols for interconnection of systems are well defined.
Before defining some architecture lets break down the system to it's main components. These are User Interaction devices, like Headset, PTT Button and Screens for the selection of Voiceloops, some backend for Voiceloop mixing and Distribution, as well as a suite of protocols connecting backend and user frontend. This is a classical client server environment. We are aware that other architectural approaches may fit the requirements for VoCS systems, but the traditional client server approach suggests itself.
Upto now noone defined some protocol stack to be used between clients and servers in such environments. The systems used are highly integrated properitary Turn-Key solutions. Openvocs intends to break down some simple and straight forward architecture for Mission Control Room Communications.
We intend to define at least as possible to leave enough room for system vendors to fill gaps or intergrate their own solutions. We strive for open connectivity between client and server environments and implement the reference architecture using the protocol suite we define. To learn more about our protocol suite have a look at the openvocs API
First of all openvocs defines a set of communication protocols to connect client and server environments. The openvocs API. This API defines the required message exchanges needed. The openvocs API is based on Webtechnologies. This allows to build lightweight clients within webbrowsers, as well as dedicated client implementation in all kind of languages.
Secondary openvocs is a reference implementation of the protocol and a fully functional production ready environment. Our Reference implementation contains of a Webclient and a dedicated media mixing backend based on microservices, connected over load balancers.
© 2024 openvocs - All rights reserved.