SMCS, el Sistema de Comando de Submarinos , se crea por primera vez para la Marina Real del Reino Unido 's Vanguard submarinos -class como un sistema de información táctica y un torpedo sistema de control de armas. Ahora también se han instalado versiones en todas las clases activas de submarinos de la Royal Navy.
Con la decisión en 1983 de construir una nueva clase de submarino para llevar el sistema de misiles Trident , el Ministerio de Defensa (MoD) del Reino Unido organizó una competencia abierta para el sistema de comando. Hasta ese momento, todos los barcos y submarinos de la Royal Navy (RN) tenían sistemas de comando construidos por Ferranti utilizando componentes electrónicos personalizados y procesadores patentados especializados. En una desviación de la práctica anterior, que había favorecido las políticas de "contratistas preferidos", la competencia fue ganada por una nueva empresa llamada Gresham-CAP, que lidera un consorcio de Gresham-Lion (ahora parte de Ultra Electronics plc) y CAP Scientific .
El consorcio propuso un novedoso sistema de procesamiento distribuido basado en procesadores comerciales listos para usar (COTS), con una arquitectura de software modular escrita en gran parte en el lenguaje de programación Ada . Cada conjunto de equipos SMCS de fase inicial tiene varios nodos informáticos. [1] En el centro del sistema hay un nodo de entrada / salida (que proporciona interfaces para armas y sensores) y un nodo de servicios centrales (que contiene procesadores numéricos rápidos). Cada nodo central se duplica para crear un sistema tolerante a fallas que es dual modular redundante . La interfaz hombre-computadora es proporcionada por consolas multifunción y algunos terminales adicionales. [2] Los nodos centrales redundantes duales están vinculados entre sí y a las consolas a través de una LAN de fibra óptica redundante dual.
En el equipo de fase inicial instalado en los submarinos de clase Vanguard , la mayor parte del procesamiento se realiza mediante computadoras de placa única Intel 80386 , cada una con su propio entorno de tiempo de ejecución Ada. CAP Scientific creó una capa compleja de middleware para vincular los numerosos procesadores. En su momento, SMCS era el proyecto Ada más grande hasta ahora visto. Como usuario pionero de Ada, el proyecto SMCS encontró muchos problemas iniciales con el uso a gran escala de compiladores Ada, herramientas de desarrollo Ada y las características especiales del dialecto temprano del lenguaje de programación Ada , más tarde conocido como Ada 83.
En 1991, CAP Scientific era parte de Sema Group y el proyecto SMCS era propiedad de BAeSEMA , una empresa conjunta entre Sema Group y British Aerospace . Una vez que se demostró que SMCS funcionaba en los barcos Vanguard , a principios de la década de 1990 se propuso extender su uso a los submarinos de la clase Swiftsure y los submarinos de la clase Trafalgar , como parte de un programa de mejora para estos barcos. Existía un deseo comercial de una mayor adopción de la tecnología COTS. El consenso fue portar SMCS a alguna forma de UNIX. Sema Group, con considerable experiencia tanto en sistemas en tiempo real como en UNIX comercial, tenía preocupaciones sobre la viabilidad tecnológica de este puerto. La esencia del problema era la necesidad de mapear el entorno de tareas de Ada con el modelo en tiempo de ejecución de los procesos UNIX de una manera que conservara las características en tiempo real de SMCS lo suficiente como para mantener la confiabilidad . Un equipo de BAeSEMA, dirigido por Ray Foulkes, llevó a cabo una investigación exhaustiva sobre posibles alternativas a la arquitectura Ada distribuida utilizada en la fase inicial. Después de una extensa investigación del comportamiento en tiempo de ejecución de diferentes variantes de UNIX y del código generado por diferentes compiladores de Ada, el proyecto seleccionó el sistema operativo Solaris que se ejecuta en SPARC.computadoras, que ahora podrían adquirirse como computadoras de placa única COTS .
Para limitar el riesgo, solo las consolas se convirtieron a Solaris en SPARC en esta fase. Los nodos centrales se mantuvieron en la misma forma que el equipo de la Fase Inicial. El beneficio fue que no hubo necesidad de implementar el esquema de redundancia modular dual en Solaris en esta etapa. Sin embargo, el proyecto tuvo que gestionar algunos problemas adicionales que surgen del trabajo mixto intel / SPARC, como el endianismo (ya que la arquitectura intel es little-endian y SPARC es big-endian ).