ADVANCE technology demonstrator · 2016. 12. 5. · dian armoured fighting vehicles are made, based on the outcome of studies, laboratory testing and hardware integration trials conducted

ADVANCE technology demonstrator Vetronics – recommended architecture for Canadian Armoured Fighting Vehicles

R. Chesney DRDC Suffield

Defence R&D CanadaTechnical Report

DRDC Suffield TR 2012-048

August 2012

Defence Research and Recherche et développement Development Canada pour la défense Canada

ADVANCE technology demonstrator Vetronics – recommended architecture for Canadian armoured fighting vehicles

R. ChesneyDRDC – Suffield

Defence Research and Development CanadaTechnical ReportDRDC Suffield TR 2012-048August 2012

Principal Author

Robert Chesney

Approved by

D. Hanna

Head Autonomous Intelligent Systems Section

Approved for release by

R. Clewley

A/Chairman Document Review Panel

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2012

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2012

Abstract

Recommendations for the introduction of a common electronic architecture for Cana-dian armoured fighting vehicles are made, based on the outcome of studies, laboratory testing and hardware integration trials conducted under the Advanced Vehicle Ar-chitecture for a Net-enabled Combat Environment Technology Demonstrator Project (ADVANCE TDP). Technical requirements are derived from an analysis of opera-tional requirements based on current operational capability requirements and forecast future requirements.

An objective architecture is defined based on readily available commercial standards and integration methods to best meet the technical requirements. The use of system-of-systems engineering practices to apply common architecture concepts to exploit commonality in off the shelf platforms is recommended to coordinate all aspects of life-cycle engineering from initial fielding through major upgrades.

Resume

DRDC Suffield TR 2012-048 i

Des recommandations concernant l’introduction d’une architecture électronique commune aux véhicules de combat blindés canadiens sont faites et sont basées sur le résultat d’études, d’essais en laboratoire et d’essais d’intégration de matériel effectués dans le cadre du projet de démonstration de la technologie d’architecture de véhicule avancée pour environnement de combat réseau-centrique (ADVANCE TDP). Les exigences techniques découlent d’une analyse des exigences opérationnelles basées sur les exigences de capacité opérationnelle courantes et sur les exigences prévues.

Une architecture objective est définie sur la base des méthodes d’intégration et des normes commerciales facilement disponibles pour respecter le mieux possible les exigences techniques. L’utilisation de pratiques techniques de système pour appliquer des concepts d’architecture commune pour exploiter le caractère commun des plates formes standard est recommandée pour coordonner tous les aspects de l’ingénierie du cycle de vie de la mise en service initiale jusqu’aux mises à jour importantes.

This page intentionally left blank.

ii DRDC Suffield TR 2012-048

Executive summary

ADVANCE technology demonstratorVetronics – recommended architecture for Canadian armoured fighting vehicles

R. Chesney; DRDC Suffield TR 2012-048; Defence Research and DevelopmentCanada; August 2012.

Background: High expectations for improved capability and survivability exist for new armoured fighting vehicles (AFVs) or major upgrades of current p latforms. Much of the forecast capability gain is contingent upon the effective integration and exploita-tion of more modern electronic systems in the platform. Improved sensors, fire control systems, tactical data visualization, navigation systems, and platform diagnostics will increase capability within the platform; improved communications will link vehicles to network information sources and allow collaborative engagement between vehicles or vehicles and dismounts. These increased capabilities come with a commensurate increase in complexity that rapidly becomes unmanageable (in acquisition, use and maintenance) unless it is managed and integrated in a consistent manner.

Common vehicle system integration (vetronics) standards based on a consistent ar-chitectural approach allow the complexity to be managed. Investment in integration effort can be reused between systems installed on a platform and common systems can be used on multiple vehicles. A common architecture allows the deployment of “plug and play” systems where upgrades or replacements can be integrated with minimal impact on other systems in the vehicle. Incremental capability upgrades are enabled, integration risk is reduced, and obsolescence management is simplified. Common support systems for training and maintenance can also be considered, allowing these costs to be shared among all platforms equipped with the common architecture.

Defence Research and Development Canada (DRDC) implemented the Advanced Ve-hicle Architecture for a Net-enabled Combat Environment technology demonstration project (ADVANCE TDP) in 2007 to investigate and demonstrate the potential for common vetronics standards in Canadian Forces (CF) combat platforms and to select and propose a set of common standards and approaches (a vehicle architecture) for consideration by the CF.

Results: The ADVANCE TDP has conducted a design study, laboratory tests and user field evaluations to select standards to define a common vehicle architecture that can fully meet the capability expectations of the Canadian Army for new platforms. A demonstrator vehicle was integrated and used for field trials that evaluated user functional priorities and interface concerns. The architecture selected uses commer-cial off the shelf standards that have broad industrial acceptance and long projected life spans for support. Integration with the evolving Land Command Support System

DRDC Suffield TR 2012-048 iii

(LCSS)equipment capabilities is considered and is fully supported, including consid-eration of information security issues.

Significance: Evolution toward a common vetronics architecture for all vehicles within the Family of Land Combat Systems (FLCS) would allow the projects to exploit consistent crew station capabilities, common training systems, common in-terfaces to the command and control system, and enable them for future upgrades with reduced effort on non-recurring engineering. Even where military off the shelf platforms are exploited, common approaches to integration of communication equip-ment and upgrades can exploit a “system of systems” engineering discipline, based on common architecture concepts, to achieve cost efficiencies.

Future Plans: The ADVANCE TDP has completed and the ADVANCE demon-strator has been transferred to the Army to act as a generic integration test platform to validate integration concepts for LCSS integration into new platforms. It is rec-ommended that the Army adopt rigorous coordination of life-cycle engineering of all platforms in the FLCS to ensure effective interoperability in combat operations.

Further DRDC effort relating to vehicle systems integration and integration of combat platforms into the force structure is being defined as a component of the routine DRDC program development process.

iv DRDC Suffield TR 2012-048

Sommaire

ADVANCE technology demonstratorVetronics – recommended architecture for Canadian armoured fighting vehicles

R. Chesney ; DRDC Suffield TR 2012-048 ; Recherche et developpement pour ladefense Canada ; aout 2012.

DRDC Suffield TR 2012-048 v

Introduction : Il existe des attentes élevées en matière de survivabilité et de capacité améliorées pour les nouveaux véhicules de combat blindés (VCB) ou pour les mises à jour importantes des plates formes actuelles. Une bonne partie des gains de capacité prévus dépend de l’intégration et de l’exploitation efficaces de systèmes électroniques plus modernes dans la plate forme. Des capteurs, des systèmes de conduite de tir, une visualisation de données tactiques, des systèmes de navigation et des diagnostics de plate forme améliorés augmenteront la capacité au sein de la plate forme; des communications améliorées relieront les véhicules aux sources d’information en réseau et permettront un engagement collaboratif entre les véhicules ou entre les véhicules et les personnes à pied. Ces capacités augmentées sont accompagnées d’une augmentation proportionnelle en matière de complexité qui devient rapidement ingérable (en matière d’acquisitions, d’utilisation et de maintenance) à moins qu’elle ne soit gérée et intégrée de façon harmonieuse.

Des normes d’intégration de système de véhicule communes (vétronique) basées sur une approche architecturale harmonieuse permettent de gérer la complexité. Les investissements en matière d’efforts d’intégration peuvent être réutilisés entre les systèmes posés sur une plate forme, et les systèmes communs peuvent être utilisés sur de nombreux véhicules. Une architecture commune permet de déployer des systèmes « plug and play » où des mises à jour ou des remplacements peuvent être intégrés avec un impact minimal sur les autres systèmes du véhicule. Des mises à jour de capacité de type incrémentiel sont rendues possibles, les risques d’intégration sont réduits et la gestion de l’obsolescence est simplifiée. Les systèmes de soutien communs pour la formation et la maintenance peuvent aussi être considérés, ce qui permet de partager les coûts parmi toutes les plates formes munies de l‘architecture commune.

Recherche et développement pour la défense Canada (RDDC) a mis en œuvre le projet de démonstration de la technologie d’architecture de véhicule avancée pour environnement de combat réseau centrique (ADVANCE TDP) en 2007 afin d’étudier et de démontrer le potentiel des normes communes en vétronique au sein des plates formes de combat des Forces canadiennes (FC) et de choisir et de proposer un ensemble de normes et d’approches (une architecture de véhicule) communes à considérer par les FC.

vi DRDC Suffield TR 2012-048

Résultats : Les responsables de l’ADVANCE TDP ont effectué une étude de conception, des essais en laboratoire et des évaluations sur le terrain par les utilisateurs pour choisir des normes afin de définir une architecture de véhicule commune qui peut répondre entièrement aux attentes en matière de capacité de l’armée canadienne pour les nouvelles plates formes. Un véhicule démonstrateur a été intégré et utilisé pour les essais sur le terrain qui permettaient d’évaluer les inquiétudes en matière d’interface et les priorités fonctionnelles des utilisateurs. L’architecture choisie utilise des normes commerciales standard qui sont largement acceptées dans l’industrie et ont une longue durée de vie prévue pour le soutien. L’intégration avec les capacités évolutives du système de soutien du commandement de la Force terrestre (SSCFT) est considérée et est entièrement soutenue, y compris la considération des questions de sécurité des renseignements.

Portée : Une évolution vers une architecture commune (vétronique) pour tous les véhicules au sein de la famille de systèmes de combat terrestre (FSCT) permettrait aux projets d’utiliser des capacités constantes en matière de poste d’équipage, de systèmes de formation communs, d’interfaces communes pour le système de commandement et de contrôle, et leur permettrait d’effectuer les futures mises à jour avec un effort réduit en matière d’ingénierie non récurrente. Même lorsque des plates formes militaires standard sont exploitées, des approches communes concernant l’intégration de l’équipement de communication et des mises à jour peuvent permettre d’exploiter une discipline technique « système de systèmes », basée sur des concepts d’architecture commune, pour atteindre la rentabilité.

Recherches futures : L’ADVANCE TDP est complété et le démonstrateur ADVANCE a été transféré à l’armée pour servir de plate forme d’essai d’intégration de type générique pour valider les concepts d’intégration en vue de l’intégration du SSCFT dans les nouvelles plates formes. On recommande que l’armée adopte une coordination rigoureuse de l’ingénierie de cycle de vie de toutes les plates formes au sein de la FSCT pour assurer une interopérabilité efficace dans les opérations de combat.

L’effort supplémentaire de la part de RDDC en matière d’intégration des systèmes de véhicule et d’intégration des plates formes de combat dans la structure de forces est une composante du développement du programme de RDDC de routine.

Table of contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Resume' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Sommaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 ADVANCE project team . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Operational capability enablers . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Common simulation training systems . . . . . . . . . . . . 4

2.1.2 Mission event capture . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Common crew stations . . . . . . . . . . . . . . . . . . . . 6

2.2 Information and knowledge . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Local situation awareness . . . . . . . . . . . . . . . . . . 7

2.2.2 Shared situational awareness . . . . . . . . . . . . . . . . . 7

2.2.3 Tactical situational awareness . . . . . . . . . . . . . . . . 8

2.3 Engagement time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Workload reduction / management . . . . . . . . . . . . . 9

2.3.2 Effective tactical visualization . . . . . . . . . . . . . . . . 10

2.3.3 Additional image sources . . . . . . . . . . . . . . . . . . . . 10

2.3.4 Automated target detection and cuing . . . . . . . . . . . . . 10

DRDC Suffield TR 2012-048 vii

2.3.5 Weapon aiming integration . . . . . . . . . . . . . . . . . . . . 10

2.4 Operational tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Automated reporting . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.2 Shared planning tools . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.3 Integrated logistic support . . . . . . . . . . . . . . . . . . . . 12

2.5 Precision effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 Direct fire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2 Non-Line of sight fires . . . . . . . . . . . . . . . . . . . . . . 13

2.5.3 Beyond line of sight fires . . . . . . . . . . . . . . . . . . . . 13

2.6 Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6.1 Threat analysis and awareness . . . . . . . . . . . . . . . . . . 14

2.6.2 Sensor evolution . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6.3 Payload integration and management . . . . . . . . . . . . . . 14

2.6.4 Platform capability control . . . . . . . . . . . . . . . . . . . . 15

2.7 Information security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7.1 Vehicle information sensitivity . . . . . . . . . . . . . . . . . 15

2.7.2 Tactical information security . . . . . . . . . . . . . . . . . . 16

2.8 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.8.1 Logistic sustainment . . . . . . . . . . . . . . . . . . . . . . 17

2.8.2 Condition based maintenance . . . . . . . . . . . . . . . . 17

2.8.3 Fleet life cycle cost . . . . . . . . . . . . . . . . . . . . . . 17

3 Vehicle architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Control layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Video/Imaging layer . . . . . . . . . . . . . . . . . . . . . . . . . . 21

viii DRDC Suffield TR 2012-048

3.2.1 Bearer (Physical Layer) options . . . . . . . . . . . . . . . . 23

3.2.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.3 Video compression . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.3.1 MJPEG / MJPEG2000 . . . . . . . . . . . . . . . . 25

3.2.3.2 MPEG-2 . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.3.3 MPEG-4 / H.264 . . . . . . . . . . . . . . . . . . 26

3.2.3.4 Enhanced Compression Wavelet (ECW) . . . . . . 27

3.2.3.5 Recommended compression options . . . . . . . . 27

3.2.4 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Information layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Secure layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Rotary base junctions . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 Summary of objective architecture . . . . . . . . . . . . . . . . . . . . 31

3.7 Related national programmes . . . . . . . . . . . . . . . . . . . . . . 33

4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

List of acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

DRDC Suffield TR 2012-048 ix

List of figures

Figure 1: Representative example of objective architecture (Turret) . . . 32

Figure 2: Representative example of objective architecture (hull) . . . . . 32

List of tables

Table 1: Technical criteria summary for CAN Protocols in STANAG 4628 21

Table 2: Image requirements for typical AFV tasks . . . . . . . . . . . . . 22

Table 3: Data rates for commonly available imagers . . . . . . . . . . . . . 23

Table 4: Related national vetronics architectures . . . . . . . . . . . . . . . 34

x DRDC Suffield TR 2012-048

1 Background

Armoured Fighting Vehicles (AFVs) are becoming increasingly complex as expecta-tions for capability and survivability rise. Adding target geo-location capabilities,sophisticated fire control systems, multi-camera situational awareness systems, digi-tal communications and proliferating access to command and control information alladd to the complexity of the vehicles. To support these capabilities the CanadianArmed Forces (CAF) has also made major investments in a net-enabled operatingcapability, deploying additional sensors, communications, and indirect fire support.

These capabilities raise the complexity of modern vehicles to the extent that it isessentially impossible to successfully integrate all of the capabilities in the traditional,ad hoc, system by system approach. There is insufficient space for discrete “stove-piped” displays and controls, while the cable burden for all of the point to pointwiring required is difficult to manage.

Adoption of computer networking principles as the core of a vehicle system integra-tion strategy alleviates many of these challenges, through routing signals from manysystems on common networks and using multi-function computer displays to allow thecrew to monitor and control multiple systems from one screen. Additional benefitsresult from the ability to allow access to all vehicle systems from any crew position,allowing crew workloads to be balanced based on need rather than physical access tothe controls of a particular system.

Through-life upgrades to respond to changing threats, to exploit new technologiesor simply to manage obsolescence are also enabled, as both the network and thecrew workstation can readily accommodate new systems. Such a “plug-and-play”architecture would allow the CAF to be much more agile in configuring vehicles forthe specific requirements of a particular deployment and to react to evolution of thethreat in theatre.

Similar challenges exist in the aircraft industry and the term vetronics is derivativefrom the use of the word avionics in that context. While avionics and vetronics arerelated, most vetronics effort and research has been much more cost sensitive andrelied upon exploitation of commercial standards, products and practices to a highdegree. Significant elements of military vetronics practice are drawn wholesale fromcommercial automotive use in trucks, buses, and passenger cars. This industrial ex-perience indicates that using standardized interfaces allows for reuse of design effortwithin individual vehicle designs and, more importantly, across multiple vehicle vari-ants and types. This reduces design cost and design lead times. Overall costs ofvetronic enabled designs are clearly also competitive in production, as witnessed bytheir broad use in the commercial automotive sector where design costs are amortizedover productions runs that are routinely in the hundreds of thousands.

DRDC Suffield TR 2012-048 1

While automotive vetronics provides some capability, military vehicles have vastlydifferent roles and requirements. Multiple crew positions, limited reliance on directview through windshields, weapon requirements, and routine communication betweenvehicles all motivate more capable vehicle architectures in military vetronics. Militaryapplications have a much greater focus on integration of the “system of systems” toprovide an overall combat capability than they are about integration of the individualsystems.

Defence Research and Development Canada (DRDC) formulated the Advanced Ve-hicle Architecture for a Net-enabled Combat Environment technology demonstrationproject (ADVANCE TDP) to:

• investigate the current and future system integration requirements for CAFcombat vehicles;

• to demonstrate the potential for common vetronics standards in CAF combatplatforms;

• to select and propose a set of common standards and approaches (a vehiclearchitecture) for consideration by the CF; and,

• to identify issues and concerns relating to integrating vetronics equipped vehi-cles into a networked communications environment.

The hardware component of the vehicle architecture defined and evaluated in thisproject is described. While the ADVANCE TDP initially focused on recommenda-tions for platform integration methods, the effort also extended to consideration ofrequirements and methods for integrating communications and command and con-trol into platforms in the context of small units — groups of vehicles or vehicles anddismounts. While the platform integration methods that are described in this reportare most effective in the context to new vehicle development, much of the approachcan still be exploited with military off the shelf platforms to establish fleet wide ap-proaches to support, maintenance and upgrade of the CAF vehicle fleet. The new andupgraded platforms of the Family of Land Combat Vehicles will need to inter-operateas a combat team when deployed, and it is appropriate that the Army move to asystem-of-systems engineering discipline to coordinate their in-service life cycle.

A companion report will be published1 that addresses the integration of vetronicsenabled vehicles into combat teams — the “net-enabled combat environment” com-ponent of the project scope.

1Nominally entitled ADVANCE Technology Demonstrator Final Report – Vehicle IntegrationRequirements for a Net-enabled Combat Environment

2 DRDC Suffield TR 2012-048

1.1 ADVANCE project teamThe ADVANCE project was originally approved for definition in April of 2005. Afteran extended project definition phase, the project was approved for implementation inlate 2006. The lead centre for the ADVANCE effort was DRDC Suffield, through theAutonomous Intelligent Systems Section. The ADVANCE project was coordinatedas an integrated project team, with effort from DRDC Suffield, the Canadian ArmedForces, and several contractors. DRDC Suffield provided scientific direction, overallproject management and contributed several sub-systems to the integration effort.The CAF acted as the sponsor for the effort, provided an Exploitation Manager, andCAF members for user groups and user trials. Significant additional support wasprovided by the Army through the the Director Land Combat System Project Man-agement (DLCSPM) in support of the integration of communication infrastructure.

The lead contractor was General Dynamics Canada (GDC). They were tasked withimplementing the architecture analysis, technical evaluation of the architecture, andto prepare and integrate the architecture in the primary vehicle demonstrator (a CAFCoyote command variant).

This project was supported by a second contract with CAE Professional Services(CAE PS)to support user requirements analysis, validation and verification strat-egy, trial design, usability assessment and data analysis that was placed with CAEProfessional Services. The Prairie Agricultural Machinery Institute also contributedthrough the integration of a limited subset of the architecture in a heavy truck (MAN7.5 ton 6x6) to demonstrate the applicability to the logistic support fleet.


2 Operational capability enablersVetronics addresses consistent design standards (an “architecture”) that allow ahigher aggregate level of capability in a platform and provides the tools to improveexploitation of those capabilities by the crew. While any discussion of vetronics isilluminated by a list of the capabilities that it supports being integrated onto a vehi-cle, a vehicle architecture definition is not about providing specific capabilities; ratherit provides for the integration of a diverse range of capabilities — both at originalproduction and over the life span of the vehicle.

Importantly, a common set of integration standards provides for a reduction in non-recurring engineering (NRE) costs, through reuse of design effort within a platformor through the reuse of designs and software modules between platforms. Militarysystems acquisition is typified by a high percentage of acquisition cost being NRE,both with respect to initial acquisition and upgrade and obsolescence management.Savings in NRE on an individual platform, or over a fleet, translate into an ability toprovide more platforms within a given budget envelope.

Specific capability requirements will change with time, operating environment, andchanging threats within an environment. As a result, analysis of future technicalrequirements under the ADVANCE project was based on broad categories of capabil-ities that might enable mission success rather than specific capability instances thatexist in current platforms. A discussion of how use of a common architecture couldimpact these operational capability enablers follows. It must be noted that while avetronics network will enable all of the capabilities identified below, further require-ments analysis would be required to select specific sets of capabilities for exploitationin any particular mix of vehicle types.

2.1 TrainingSuperior training is a key enabler for mission success. Superior numbers and firepowerare never guaranteed, and technological superiority can be fleeting. Uncompromisingcommitment to comprehensive, relevant training enables the independent action thatcan allow the Canadian Army to succeed in the face of obstacles. Vetronics supportsa rich training environment through enabling the capabilities noted below.

2.1.1 Common simulation training systems

A vetronics architecture allows for the ready injection of simulated imagery and datainto the vehicle network. Attached simulators can generate image streams replacingthose that would be generated from weapon sights or situational awareness imagers onthe vehicle. At a network level, the crew workstation merely “sees” the same format


of imagery from another source. Transitioning to a simulated training environmentmerely requires connection of standard network cables to the vehicle and selection ofa network configuration to switch to the training simulation.

While the vetronics approach can simplify the generation of training simulation toolsfor a single platform, the real advantage is gained when those simulation tools canbe leveraged across an entire fleet. A fleet-wide common vehicle architecture al-lows the same simulation system to be used on any platform, changing only minorconfiguration files to tailor the simulation to the appropriate vehicle dynamics andweapon models. Individual vehicle training can then be readily extended to collectivetraining. Rather than having disparate simulation systems merely share a commondatabase of “players” in the simulation, they can all share exactly the same underly-ing image generators and performance models so that all trainees share in the sameenvironment.

Moving to a common simulation training system for multiple platforms could also beexpected to simplify management of the systems, provide for consistent simulationfidelity, and lower acquisition and support costs.

2.1.2 Mission event capture

Placing all of the imagery and vehicle state information on common networks allowsfor the routine recording of information on the platform, either by the computersassociated with the crew workstations or through the installation of a dedicated“black box” recorder. Once this capability exists, it can be configured to capturedata from operational missions to be used to debrief after missions, to provide datafor incident investigations, or to provide realistic training material. The data capturecould be extended as desired, limited only by the capacity of the recording deviceand overall vehicle network loading. Examples of data that could be recorded include(but are not limited to):

• vehicle position, heading and speed;

• detailed driving information such as throttle position, braking force and steeringangle;

• weapon sight images or image sequences;

• images or image sequences from the driving camera(s) and any other situationalawareness imagers; and

• ammunition type fired.


Data could be continuously recorded in the manner of a aircraft black box, whereall data and imagery is preserved and eventually overwritten if no event occurs thatstops the recording, or data could be recorded only as the result of a specific event,such as the crew lasing a target, or firing the vehicle’s weapon.

2.1.3 Common crew stations

Vetronics provides for common crew station design elements. While its physical layoutmay force differing screen sizes, orientations, and interface controls that are specificto a vehicle type or a crew position in the vehicle, much of the way that a crew stationworks can evolve to a standardized “look and feel”. Common methods of operationof the driver workstation, the gunner workstation and ultimately the commandersworkstation would allow crew progression training to focus on the tasks associatedwith each role, as opposed to the mechanics of operating the specific interface. Com-mon crew station designs between vehicles would also allow for reduction in trainingdevelopment effort, allowing much of the training for equivalent roles (driver, gunner,etc.) to be shared. Transition training between vehicles would be simplified, allowingcrew members to readily transition between vehicle types.

2.2 Information and knowledgeThe relevance of information for units in direct contact with the opposition (includingindividual vehicles) is directly related to the “age” or latency of the information.The area of interest for an individual vehicle is largely bounded by the range of itssensors, weaponry and the distance of the current tactical bound. It will rarely exceed5000 metres. Mounted opposition forces could move this distance in as little as 5-10minutes. As a result a red force tactical picture that portrays enemy positions olderthan a few minutes could be catastrophically misleading. The workload to interpreta “stale” tactical picture could reduce or eliminate the commander’s contribution tofighting the vehicle and maintaining local situational awareness. Low latency targetinformation passed from adjacent units can assist in tactical situational awarenessfor the vehicle commander and have significant relevance; however, even in this case,discrete target reports need to be interpreted. An individual commander may not beable to readily distinguish between multiple reports of the same target at differentpositions (as it moves through cover) and reports of multiple targets.

Ultimately, the information requirements for individual vehicles and small units arebounded by the cognitive limits of the crew. It is readily possible to reach a state ofinformation overload, where the crew effectiveness can be degraded by the effort tofilter information, or through distraction as new information is made available.


2.2.1 Local situation awareness

Efforts to protect vehicle crews through improved armour, shock protective seating,and seat restraints have all reduced the ability of vehicle crews to maintain situationalawareness around their vehicles. Exploiting additional sensors to eliminate this deficit(or ultimately to exceed to capability of an exposed crew) would improve the abilityto execute many aspects of the mission. For the purpose of analyzing the potentialimpact of vetronics, local situational awareness is considered to include all perceptionrequirements for the vehicle including driving, obstacle assessment for manoeuvre,threat detection/awareness, and target acquisition. All of these roles can be met (toa greater or lesser extent) by the addition of electronic imagers.

A consistent vetronics architecture can provide the mechanism to add large numbersof imagers, to meet the optical requirements of each specific role, to cover the numberof look angles required to see around the vehicle, and to allow the use of alternativetypes of imagers (infrared or hyper-spectral) when required. Most importantly, aconsistent vetronics architecture would allow all of these imagers to be viewed fromeach crew position’s display. With this capability, the space claim and human factorsfor the display positioning can be optimized for each crew position, independent ofthe number and type of imagers that ultimately are added to the vehicle. Multipledisplays can be used at crew stations where space permits. Within constraints ofthe available resolution for the crew displays used, multiple imagers can be displayedsimultaneously in independent windows. The vetronics network would allow all ofthe imagery to be handled in the same manner, allowing all crew positions to see anyimage source as required by the mission. For example, the commander can readilyselect the weapon sight that the gunner is monitoring to confirm a target, or selectviews from the driving cameras to direct the driver at intersections or crossroads.

The vetronics architecture will allow sensors to be replaced or augmented as tech-nology evolves, or to tailor performance to the conditions of a particular theatre ofoperations. Integration effort would be largely constrained to mechanical mounting ofthe sensor and installation of an appropriate software driver in the crew workstation.Full integration of all image displays allows consistent methods for target designation,providing for seamless transfer of target bearings from situational awareness imagersto weapons.

2.2.2 Shared situational awareness

Vehicles will very rarely operate independently in a mission. Enhancing the abilityof groups of vehicles to share information, or for vehicles to share information withnearby dismounts, is another enabler for effective mission execution. The vetronicsarchitecture will allow the ready sharing of target positions and image snapshots. Fullintegration of these capabilities would allow the weapon/sighting system to automat-


ically align to a known target position and it would allow the simultaneous displayof image snapshots from a dismount (or adjacent vehicle) with live imagery from thevehicle imagers. Once the basic architecture is in place, annotation overlays can beadded to the imagery and transferred in real time between crew positions within avehicle and between adjacent vehicles. Exploiting shared imagery can be expected tospeed descriptions of objectives and desired manoeuvres and targets.

A vetronics architecture would also allow the ready incorporation of other classes ofexternal sensors, such as feeds from unmanned air vehicles and unmanned groundvehicles. Real time feeds from these types of platforms may require the additionof dedicated communications equipment, but the display of the imagery and thegeneration of control inputs can be accommodated within the crew workstations in asimilar manner to any on-board image source.

Shared situational awareness is enabled by the vetronics infrastructure, but it mustleverage a communications infrastructure to transfer information. Information rout-ing and prioritization to achieve relevant target position latencies needs to be carefullyconsidered. This aspect is more thoroughly addressed in the companion report thataddresses the net-enabled combat environment component of the project.

2.2.3 Tactical situational awareness

While a traditional “common operating picture” may have reduced relevance to com-manders of individual vehicles due to the “stale” nature of the information, thereis much static information than can be exploited, along with real-time display offriendly force locations. Augmenting digital maps with the use of airborne imagerymerged with terrain height information could provide very simple visualization toolsto allow the rapid assimilation of force positions relative to the objective and allowplanning for the best use of terrain.

A fully integrated vehicle allows for the bearing of blue force units (and currentopposition positions) to be displayed as overlays on any video image, including drivingcameras, the weapon sights or an independent commander’s sight. Coupled with sightcoverage and weapon aim point overlays on the digital map, the spatial relationshipsof the vehicle to adjacent units can be made much simpler to assimilate.

Full integration of the vision, navigation and information systems will allow for even-tual insertion of “augmented reality” applications if they prove to be warranted incombat roles. As an example, this could include the ability to label buildings inthe field of view with descriptions of how they are used, or what organization is us-ing them. Ultimately, techniques such as face recognition can be integrated to linklocal situational awareness cameras to databases of known players be they knownopponents, local government officials, or representatives of non-governmental organi-


zations. If implemented in a way that integrates with the priority work flow of thevehicle, cuing the vehicle crews to detailed information about the local environmentcan allow them to act with more sensitivity to local concerns and improve overallmission outcomes.

While tools of this class are enabled by the vetronics infrastructure, it must be stressedthat implementation may not be warranted in many cases. The impact of informationlatency, communication dropouts, and data errors must be fully evaluated in theevaluation of proposed systems, and the overall impact on crew workload and missionexecution must be evaluated in realistic scenarios.

2.3 Engagement timeThe speed with which a vehicle can respond to the inter-visibility of a threat is crucialto success. Firing first, or manoeuvring to cover, before the enemy can detect and fire,provides for much lower loss ratios. In some instances, the detection of a threat will beconstrained by the detection range of the weapon sights; however, in many instancesthe threat will be masked by terrain or cover and only become inter-visible well withinthe detection range of the sights. In these instances, the ability to scan the area ofresponsibility, detect, and respond to threats becomes the primary determinant ofreaction speed. Much of this process is determined by the performance of the crewand their ability to focus on and execute this task. In turn this is influenced by thetools that the crew has to work with. A fully integrated platform can provide moreeffective tools to support the crew.

2.3.1 Workload reduction / management

Vetronics provides several significant options to manage crew workload and to allowthe crew to focus on priority tasks. All of the vehicle “health” state is monitoredelectronically reducing the time that the crew needs to spend monitoring these func-tions. It also allows for a centralized approach for alarm / status display, so thatcritical information can be integrated into the main display, lessening the time thatthe crew needs to look away from targeting displays when they are scanning.

Scan patterns can be partially automated, either with fixed patterns or throughrepeating patterns used by the operator. This can ensure that the search area isscanned more methodically. Implementation in a vetronics network context meansthat the scan pattern can be automatically adjusted to compensate for changes invehicle position and orientation.

Vetronics allows options to better partition the workload. Access to any vehiclesystem can be made available from any crew position, rather than solely where the


system is installed. This allows tasks to be transferred among the crew, includingallowing access to crew positions in the rear as required. Further, tasks and workflows can be adjusted to meet unforeseen user requirements as the equipment installedor TTPs2 evolve.

2.3.2 Effective tactical visualization

Integrating tactical visualization tools allows the field of view of target acquisitionsights to be displayed on a digital map / aerial image representation. Dead groundcan be highlighted and limits of scan arcs and priority scan areas can be interactivelyassigned. If desired, these could be used to generate optimized scan patterns. Limitsof arcs, dead zones and even current look angle would all available as digital data totransfer to adjacent vehicles (or the unit commander) to allow rapid assessment ofthe overall scan coverage of the unit.

2.3.3 Additional image sources

A vehicle network that supports video distribution, allows additional imagers to beadded and controlled. Notably, these could include an independent commander’ssight and / or an electronically steered local situational awareness imager (LSAS)array. Once the network is in place, new sensors can be added, or existing onesupgraded, as required.

2.3.4 Automated target detection and cuing

Digital image paths allow data to be streamed to multiple users or applications.This allows vision data and related data about the vehicle and sight position andorientation to be routed to image processing applications in parallel to the display tothe operator. These applications can implement automated target tracking, detectionand identification. Overlays can then be generated to cue the operator to prioritytargets. Using a video network to implement the image processing decouples theprocessor from the sensor and the display, simplifying space claim management andallowing this class of capability to be more readily added at a later date should themilitary utility be fully proven.

2.3.5 Weapon aiming integration

Full integration of the weapon system with all sources of target positions (or bearings)allows the comprehensive use of “slew to cue” weapon alignment. A platform withappropriate vetronics can generate a grid position each time a target is lased, whether

2tactics, techniques and procedures


from the weapon sight or from an independent commander’s sight. This position canthen be passed within the vehicle to quickly and accurately align the weapon to thetarget position or passed to adjacent vehicles. Bearings from threat sensors, suchas laser warning receivers and sniper detection systems can also be shared on thenetwork to allow the weapon to be rapidly aligned to the threat bearing.

Equivalent alignment behaviour can be associated with an independent commander’ssight if the vehicle has one installed; allowing the commander to more rapidly assesspotential threats.

2.4 Operational tempoSustaining a rapid operational tempo – moving quickly from engagement to engage-ment – contributes to mission performance by acting faster than the enemy can re-spond. Any force will require tactical pauses to allow for crew rest, tactical planningand logistic re-supply; however, it is desirable to eliminate instances where tacticalpauses are required for administrative reasons and to reduce pauses for planning andre-supply.

2.4.1 Automated reporting

Significant time can be consumed for the compilation and coordination of after actionreports on casualties, ammunition usage and vehicle maintenance / logistic state –especially over a congested voice channel. A vetronics equipped vehicle can providea pro forma report on ammunition usage and vehicle state in real time that can beannotated by the commander and transmitted efficiently as a machine readable file.Individual vehicle states can then be consolidated at a unit level, either by a unitsupply officer, or automatically by a computer routine, and forwarded to the logisticchain.

Automated, or semi-automated reporting can also have an impact on reporting targetsmore quickly, providing a pro forma report, including target location, with any useof a laser range finder associated with a targeting sight. Efficient, accurate passageof target locations should significantly improve the pace of operations. Maintainingthe digital form allows automated inclusion in the command and control system, easyvisualization of relative positions on electronic maps and semi-automated alignmentof weapons and sights. In addition, voice transcription errors can be eliminated.

The workload associated with annotating target reports needs to be considered inexpectations for digital target reporting. While the digital position can be capturedand formatted automatically, annotation of what the target is will still require inter-vention by the crew. The annotation process needs to be exceptionally simple andrapid to avoid distracting the crew from their priority tasks.


2.4.2 Shared planning tools

Common crew workstations, supported by a vetronics network and digital communi-cations allows for the efficient integration of simple shared planning tools that couldhave positive impact for individual vehicle commanders. It becomes straightforwardto replicate the commander’s display content on other crew workstations within thevehicle, or to export it to adjacent vehicles. An integrated vetronics system supportsinteractive overlays (“white boarding”) and inter-vehicle intercom capabilities to al-low a unit commander to conduct a rapid “orders group” utilizing maps, satelliteimages, or images of the objective that may be available from any vehicle in thegroup. While much, if not all of the interaction may be quicker by voice, referringto a common basic visual plan should reduce time required, improve comprehensionand reduce errors.

A consistent vehicle architecture allows the rapid transfer of other planning elements,including waypoint lists and communication plans – with automated transfer directlyto the system using the information.

2.4.3 Integrated logistic support

As noted previously, much of the logistic and operational state of the vehicle can bereadily captured using vetronics. Newer engines and transmissions, being fitted incurrent generation AFVs, incorporate engine control units (ECUs) that can generatedetailed fault analysis and transfer this information to a network monitor node. Moremodern weapons and fire control systems can monitor rounds fired and often can senseremaining ammunition directly. Exploiting this information, along with other vehiclestate (fuel levels, etc.) available on the vehicle network allows each vehicle to exporta comprehensive logistic snapshot on demand, either for direct transmission to asupporting logistic unit, or for consolidation within a unit. Subject to communicationbandwidth constraints, near real time logistic information can enable much moreefficient re-supply planning and execution.

Enabling the direct transmission of diagnostic information from vehicle systems canalso allow maintenance personnel to prepare for vehicle repairs before they see thevehicle. A vetronic architecture also enables the vehicle for comprehensive healthand usage monitoring. Engine run time, off-road mileage, speed profiles and weaponuse can all be monitored to allow condition based maintenance rather than routinemaintenance based on dates or simple mileage quotas.

2.5 Precision effectsIn many mission scenarios faced by the Canadian Forces, the preservation of infras-tructure and the avoidance of incidental casualties and property damage directly


relates to the potential for success in the mission objectives. Fire precision and theoption to use the most appropriate weapon for the intended effect are significantenablers toward this objective.

Mission success may also be impaired by fire that is ineffective, either as a result ofinaccuracy or inadequate terminal effects. Ineffective fire imposes significant risk andcosts associated with logistic re-supply, and it also provides a psychological boost tothe enemy force.

2.5.1 Direct fire

Direct fire precision is largely a function of the weapon, fire control system and me-chanical and electro-optical integration of the turret or mount. The use of a vetronicsarchitecture will not generally impact the performance of these systems, except insecondary ways relating to the potential for better human factors and ergonomics as-sociated with consolidating system controls into a crew workstation. This may allowfor less contrived space claim management and better control placements.

2.5.2 Non-Line of sight fires

A vetronics network allows the ready integration of navigation systems and target-ing sights to generate position estimates for any target seen. Augmented by laserdesignation (when required by the weapon), this provides for the introduction andproliferation of non-line of sight weapons where the fire platform can be concealed byterrain from the target being engaged. Reducing the option for counter-fire in thismanner provides for more effective engagements against peer and near-peer forces.Non-line of sight weapons may also provide for more appropriate effects and shorterdelays in providing fire support against asymmetric threats.

Tight integration of the laser designator with the targeting sight and a digital commu-nications system can also impair the effectiveness of enemy countermeasures; allowingthe activation of the laser designator to be synchronized to the arrival time of theround.

2.5.3 Beyond line of sight fires

Target geo-location and laser designation capabilities are equally applicable to longerrange fire support including artillery, artillery rocket and air support. This providesthe broadest range of fire support options, albeit at the expense of typically longercoordination and delivery times. Transitioning the ability to call for heavy fire sup-port beyond specialized FOO / FAC (Forward Observation Officer / Forward AirController) teams may be aided by the ability to tag call for fire requests with tar-get images or image sequences. This will allow the fire control coordination team


an ability to assess the type of effect required and the weapon type that should betasked.

2.6 SurvivabilityEnhancing survivability is an obvious imperative for the Army. To this end it isimportant that the vehicle platforms are designed to accept, integrate and exploitevolving combinations of threat awareness systems, threat detection capabilities andcounter-measures; for different operating environments, or, as the threat in a partic-ular mission changes.

2.6.1 Threat analysis and awareness

Effective crew workstations allow for better exploitation of known threat data andterrain data. Merging tactical visualization on the same screens as the crew membersuse for other displays allow for much better integration with the normal workflowof the vehicle, as well as benefiting from the improved ergonomics that derives fromconsolidating sub-system displays. As noted above, full integration of the tacticaldata display with the image displays of the vehicle allow for the injection of over-lays, or highlighting, to be injected in image displays to cue the crew to the spatialrelationships of known threats.

While enabled by the vetronic integration, this class of overlay integration is subject tosignificant error sources that may impair its relevance in actual operations – notablyerrors in vehicle navigation accuracy in both position heading and attitude (pitchand roll) will result in displacement of the overlay from the intended feature in theimage. As a consequence, exploiting this type of overlay would need to be thoroughlyevaluated for utility prior to investment.

2.6.2 Sensor evolution

A vetronics architecture provides for common interface standards for sensors andthe ability to change systems in a “plug and play” manner. This allows the rapidintroduction of specialized sensors that are specific to a threat. This could includespecialized imagers, detection systems, or additional defensive aid suite components.

2.6.3 Payload integration and management

Additional payloads can also be readily integrated into a vetronics enabled vehicle.These could be as complex as the addition of a remote weapon station or a full activedefence system; or, as simple as the addition of an additional rear compartment


light. The network allows the routine transfer of all system information between sub-systems, so a remote weapon station (RWS) could use the same controls and displaysas any other weapon or steerable sight. An active defence system could readilyexploit blue force tracking in real time to update fire exclusion zones. Bearings fromconventional defensive aid suite sensors can be fully integrated to allow rapid weaponalignment, appropriate map overlays, and manoeuvre guidance for the commanderand driver. Configuration, monitoring and control of additional subsystems can beintegrated into the crew workstation with the addition of software device drivers andupdated display software.

2.6.4 Platform capability control

Vetronics also allows for implementing and integrating operator controls for platformoptions that contribute to survivability. Actuators for ride height management couldbe readily integrated as part of a vetronics network and operator controls for thatcapability and a variety of other systems, including electronic stability control andactive suspensions, could be combined into a common crew workstation. Commonapproaches to integration can result in more effective implementations; for example,allowing the electronic stability system to monitor the ride height setting and adjustthe control algorithm for changes in the vehicle centre of gravity.

2.7 Information securityFront line combat vehicles have a range of information security concerns and issues,each with associated time sensitivities; however, it should be recognized that thevast majority of information developed or accessed in combat vehicles has only tran-sient sensitivity. Much of the electronic infrastructure that the CAF has deployedto date has been certified to secure data to the Secret level, entailing severe costsin design, qualification and certification. Extending this level of certification to allaspects of the vehicle electronics is unaffordable, and the delays and effort associatedwith qualification and certification of each configuration would eliminate any “plugand play” benefits that accrue from a common architecture. Violating good securitydesign practice to interconnect secure infrastructure with unqualified equipment in-validates much of the original investment in secure communication equipment andsystem certification.

2.7.1 Vehicle information sensitivity

Obscuring the technical capabilities of sensors and weapons is often cited as a re-quirement to secure data, such that the opposition force remains uninformed aboutthe technological capabilities of the combat platform or its sensors. While this might


be a laudable objective, it should be understood that any opposition force, especiallyany peer force, can readily estimate the technical capabilities of sensors and weapons.

Sufficient information is routinely published in the open literature to reconstruct thepotential performance of sensors, and every time the platform is observed in actionperformance estimates can be confirmed. Notably, in a mission where asymmetricforces are engaged, numerous opportunities will exist for the opposition to placepotential threat “targets” at various ranges and observe whether the vehicle turretslews to confirm the target. Every time the turret slews to a target that an observercan also see, they become more informed about what the target acquisition sensorscan discriminate.

The weapons available to AFVs are limited and generally well known in the openliterature, for any given vehicle type. While the specific target suppression perfor-mance may be classified, the general range of effects is well described in the openliterature. Any opposition force with a level of state support will also have accessto specific performance data of similar weapons. In addition, any extended missiongives an opposition force very definitive empirical data on weapon performance.

The detailed state of the platform (ammunition load, sensors enabled, defensive mode)would be of value to an enemy force in real time, but has little value after a shortperiod. Techniques to extract information of this sort from a network within a vehi-cle when it is not intentionally broadcast would require formidable levels of effort.Where data of this class is intentionally broadcast it can be encrypted prior to trans-mission. Encryption sophistication can be tailored to the time sensitivity of the dataas required.

2.7.2 Tactical information security

In some instances it will be desirable to transfer tactical data with definitive securityclassification. The vehicle network/systems must include that ability to allow thevehicle commander (at a minimum) to view information of this sensitivity withina secure segment of the network. It is highly desirable that this capability not re-quire the use of a physically independent computer display as few vehicles will haveadequate space for additional displays in positions that allow full utility.

In meeting the desirable goal of providing access to secure information, it must alsobe considered that not all of the vehicle crew may be cleared to Secret. It is alsoimportant that classified data be clearly identified to the user to avoid inadvertentdisclosure.


2.8 SustainabilityIncreasing capability within vehicles must be carefully considered and balanced againstoverall mission requirements. Capability and complexity drive platform costs, bothat acquisition and through the entire life cycle. Ultimately the Land Force needs tomaintain a sufficient quantity of vehicles to establish a presence and to hold ground.Terrain limits the range of influence of any combat vehicle to such an extent that nolevel of individual capability can ultimately substitute for having sufficient numberof platforms. Lowering the overall cost of the fleet through an integrated approachto acquisition and through-life support can allow more units to be acquired withinthe available funding envelope.

2.8.1 Logistic sustainment

The use of comprehensive vehicle monitoring allows a transition of field logistics toan accurate “just in time” model where the logistic supply chain can be informed toassemble and deliver supplies based on known consumption; eliminating (or at leastlimiting) the extent to which supplies are pushed based on worst case consumptionestimates. Accurate consumption data allows the logistic chain to implement fullsupply chain management, from theatre supply, back to acquisition.

2.8.2 Condition based maintenance

A vetronics architecture allows for full monitoring of vehicle usage and sub-systemdiagnostic state. This allows routine vehicle preventative maintenance requirementsto be tailored based on actual vehicle usage rather than worst case interval cycles.Reducing preventative maintenance frequency to that actually required, both reducesmaintenance cost and improves vehicle availability.

Rapid reporting of sub-system test failures and diagnostic errors, while the vehiclesare still in the field, allows maintenance personnel to prepare and plan repair interven-tions to maximize vehicle availability. Spares can be located in advance and orderedfrom rear supply areas, if required. Vehicles with problems that can be repaired withspares on hand can be prioritized.

2.8.3 Fleet life cycle cost

A common vehicle architecture allows for common platform sub-systems to be used onall platforms throughout the fleet. Common navigation systems, radios and drivingcameras are already accepted concepts and a common architecture would allow thisto be extended to other components. More importantly, escalation of software costscan be contained as solutions to any integration problem can be leveraged betweenplatforms.


Common architectures allow solutions developed for one fleet to be exploited on allfleets. The most obvious example of this would be the use of common training andmission rehearsal kits. All of the interconnections would be identical, with limitedtailoring to accommodate the specific sensor complements and weapon options.


3 Vehicle architectureThe architecture recommended for future CAF vehicles is based on achieving hightechnical performance and growth potential at acceptable cost. As noted earlier,the adoption of a vetronics architecture is not directed to the implementation ofa specific set of current requirements, but towards configuring CAF vehicles for asuperset of requirements – allowing the flexibility and upgradeability to rapidly tailorthe capabilities of a platform to meet evolving threats and to exploit advances incomponent technologies.

Under the ADVANCE project General Dynamics Canada (GDC)was contracted fora design analysis and report. Working from a notional architecture concept providedby Defence Research and Development Canada, GDC completed a technical analysisof data flow requirements and implementation options to refine the architecture andensure that it met the requirements for the superset of requirements defined. Subse-quent to the completion of the design analysis, GDC completed an implementationof the architecture in a demonstrator vehicle to identify any integration issues thatthe analysis might have missed. Their results, updated based on the experience ofthe integration effort, are incorporated in the objective architecture described below.

The objective architecture defines a long term solution that is more complex thanthe architectures employed by other nations in their current vehicles, but does notrely on any high risk technologies. It reflects current Canadian design objectives andmany emerging trends in architectures being specified or in definition by allied na-tions. While vehicles being acquired by the CAF at present may not be compliantinitially with the objective architecture, opportunities for exploitation of componentsof the architecture to achieve the design goals of a common architecture will still beachievable, especially in respect to common solutions to communications and com-mand and control integration. The following section identifies key components fromthe architecture that can be adopted in current acquisition and fielding to enableevolution of all CAF platforms toward a common architecture.

The architecture defined by ADVANCE isolates certain data and control streamsonto independent layers depending upon the technical requirements for the transferof the data. The data streams on a combat platform have sufficient diversity thatdifferent technical solutions are appropriate. The criteria used to segregate datastreams include:

◦ typical data volume (bandwidth);◦ data volume variability (burst behaviour);◦ requirement for a known maximum delay between transmission and receipt ofthe data (deterministic latency); and,

◦ data security requirements.


Each layer of the architecture supports a different combination of these criteria. Lay-ers also allow the addition of redundant capability through the ability to reroutesome/all of the key information to maintain the operational state of the vehicle –albeit at a degraded level.

3.1 Control layerMany of the control and monitoring requirements within the vehicle have very limiteddata requirements. These might range from reporting the engine speed, or a hatchstate, through the generation of joystick positions to control the movement of theturret. These data flows fall into the broad classification of “control” requirements.These typically use short messages and have low total bandwidth requirements, butrequire very low and predictable transmission times (low/deterministic latency). Theautomotive industry has moved broadly to the use of vehicle networks to supportthis class of control, using the Controller Area Network (CAN) data bus protocoloriginally developed by Bosch and now defined by ISO 11898 (International StandardsOrganization).

The CAN bus meets most current needs of the automotive industry and can beexpected to have an extended lifetime and ongoing industrial support. It is beingaugmented by additional bus designs for multi-media and for safety critical controlaspects; but the cost of these solutions is much higher, driving commodity applica-tions to remain on the CAN bus. The ISO specification that standardizes the CANdata bus controls only some aspects of the message format and the electrical signalinglevels. The way that data is packaged in the message and the data rate at which it istransmitted is determined by a protocol specification that provides a convention forthese parameters. NATO STANAG 4628 proposed through Land Capability Group2 (LCG/2) identifies options for CAN protocols that are consistent with the require-ments of armoured fighting vehicles, in particular a group of 4 protocols (J1939,MilCAN, CANOpen and CUP) and leaves it to national policy to determine whetherthis range of options should be further restricted.

The J1939 standard was developed and is maintained by the Society of AutomotiveEngineers (SAE). It is widely used in the truck and bus community, and is almostuniversal for the control and monitoring of current generation engines and transmis-sions. As such, it can be expected that at least one segment of the control data buswill run under the J1939 protocol. The MilCAN 3 protocol was developed specifi-cally for military platforms and is maintained by an independent standards group.It is mandated for some programs in the United Kingdom and has also been used insome Swedish defence programs. The CAN Utility Protocol (CUP) was developedby Germany’s Bundesamt fur Wehrtechnik und Beschaffung (BWB, Federal Office of

3www.milcan.org


Table 1: Technical criteria summary for CAN Protocols in STANAG 4628.Protocol Standards

BodyDeterminism Complexity Industrial

Availabil-ity

MaximumBaud

Start Up

J1939 SAE No Moderate High 250 K Automatic

MilCAN MilCANWorkingGroup

Yes Low toModerate

Low 1,000 K Automatic

CANOpen CAN inAutomation

Partial High High 1,000 K Managedby cen-tralcontroller

CUP GERBWB

No Low Low 1,000 K Automatic

Defense Technology and Procurement) and is used in some German vehicle projects.CanOpen is an industrial protocol that is widely used in machine control applications.The key discriminating criteria for the four options are summarized in Table 3.1 .

It is readily possible, and often desirable, to separate segments of the control data busto reduce the data traffic on a given portion of the bus to the data items of interestwithin that fraction of the overall system, and to limit the impact of a catastrophicbus failure to a sub-set of the systems on the vehicle. Special purpose network nodes(bridges) relay traffic between segments of the control bus. Bridging functions mayalso be included in general purpose nodes that provide other functions.

Bridges also provide an option to translate from one CAN protocol to another, sonot all segments of the vehicle control network need run the same protocol. Giventhe limitations of the J1939 protocol in respect to speed, and its lack of support fordeterministic data transfers, more advanced control applications may well require adifferent protocol. To support technical requirements of this class it is recommendedthat both the J1939 and the MilCAN protocol be supported.

3.2 Video/Imaging layerApplications for video/imaging data within AFVs include target acquisition, driving,general situational awareness, and specialized threat detection. In some applications,notably target acquisition and driving, any significant delay (latency) in presentingthe image to the user will degrade the ability of the operator to perform the task.While an operator can compensate for minor amounts of delays in these tasks, thisrelies on the delay being consistent at all times. In other tasks, there is less couplingwith fine motor control and a greater latency is tolerable; however, increases in latency


Table 2: Image requirements for typical AFV tasks.

Task Max Latency Desirable FOV Resolution

Target Acquisition ∼ 60 mS 2 – 15◦ Horizontal Moderate to high

Driving ∼ 60 mS 160◦ Horizontal; 100◦ Vertical Moderate

General Situational ∼ 120 mS 160◦ – 360◦ Horizontal; Moderate to highAwareness 100◦ Vertical

Threat Detection ∼120+ mS Threat / Sensor dependent Moderate to high

will still impact the overall reaction time for the crew to complete their associatedtask. A summary of image task requirements is included in Table 2.

The field of view requirements (FOV) noted for driving approximate the FOV of thehuman eye. Vertical FOV task requirements are heavily dependent on terrain, withhigher values desirable for cresting hills, traversing dips and in close urban driving.Smaller FOVs may be acceptable under many conditions, but will limit manoeuvrespeeds or compromize driving performance in some scenarios.

Threat detection sensors could be many types including conventional optical imagers,a broad variety of radar systems, or IR or hyper-spectral imagers tailored to detectphenomena associated with sub-surface anomalies (i.e. buried munitions).

Video data is characterized by high data rates that are continuous and predictable intiming. Data rates for individual imagers based on commonly available technologyare provided in Table 3. An AFV will normally be equipped with several imagers,requiring a substantial aggregate bandwidth. Given the critical importance of imagestreams to fight and manoeuvre the vehicle, it is recommended that the video networkbe implemented in a manner that guarantees quality of service (QoS) either through adedicated network or through use of shared networks that can support QoS bandwidthpartitioning.

It should be noted that the bandwidth stated for high resolution day sight imagers inTable 3 is based upon the transfer of “raw” (Bayer format) imagery from the camerato the display – with conversion to pixel display values at the display processor.Conversion prior to transmission would significantly raise this value (on the order ofthree times).


Table 3: Data rates for commonly available imagers.

Imager Type Resolution Frame Rate Dynamic Range Typical(pixels) (Hertz) (bits / pixel) Bandwidth

IR 640 * 480 60 8 – 12 147 MIR (high Resolution) 1024 * 1024 60 12 – 16 750 MDay Sight (RS 170) 640 * 480 30 8 ∗ 3 220 MDay Sight (HDTV) 1920 * 1080 30 8 + 500 M

3.2.1 Bearer (Physical Layer) options

Several commercial standards exist for transferring digital video, including IEEE4

1394 (also know as Firewire R⃝), IEEE 802.2-2008 (Gigabit Ethernet – GigE), CameraLink R⃝, and USB (Universal Serial Bus).

Of these choices, Gigabit Ethernet supports the longest cables runs (100 m) andthe highest signaling rates. Gigabit Ethernet also supports a high power transferpotential (> 30 watts is nominally available for power over Ethernet (PoE)), allow-ing the sensor to be powered over the data cable. Commercial support for GigEis extensive. Power consumption for Gigabit Ethernet drivers and switches is alsomanageable for conduction cooled implementations with example industrial imple-mentations5 quoting only 1.5 watt/port. GigE can be implemented over fibre whererequired by electromagnetic compatibility or interference considerations.

IEEE 1394 was originally introduced with a bandwidth of 400 Mbits/second and amaximum cable length of 4.5 m. This implementation achieved significant commer-cial success and was broadly supported in both the commercial and industrial videosectors. More recent versions of the IEEE 1394 standard allow for higher data rates(800, 1600 and 3200 Mbits/second) and allow tradeoffs between data rates and cablelength; however, broad commercial exploitation has not materialized, with moderatemarket support for only the S800 variant of the standard.

Camera Link R⃝ is a digital video interface standard that was defined and is maintainedby the Automated Imaging Association (AIA). It supports high data rate transfers(> 1.5 Gigabits/second) at cable lengths up to 10 m; however, the complexity of thecable is substantially higher than that required for other standards (26 conductors vs8 for Gigabit Ethernet). Support for Camera Link is still significant in the machinevision market, but new implementations tend to use Gigabit Ethernet instead.

The USB standard continues to evolve. The recently introduced third version of

4Institute of Electrical and Electronic Engineers5MPL AG Elektronikunternehmen: MAGBES five port switch


the standard provides for data transfers at a nominal rate of 3200 Mbits/second,butpractical cable lengths are expected to be quite short — certainly less than the 5.0m associated with the v2.0 version of the standard and possibly only 3.0 m. Giventhe size of an AFV and the often complex cable routing required, such short cablelengths to sensors are not seen as viable.

Based upon the extensive industrial support for Gigabit Ethernet and the supportfor adequate cable lengths and bandwidth, the ADVANCE project selected and rec-ommends the use of Gigabit Ethernet for digital video.

3.2.2 Topology

Commercial implementations of GigE are typically implemented as a “star” topologywith all interconnections being routed through a switch. This has the disadvantageof introducing a single point of failure, as a failure of the switch will interrupt trafficfrom all connected devices.

Ring topologies are also possible, although commonly available equipment tends tobe oriented to the telecommunications or internet service provider markets. Ringimplementations are somewhat more robust, in that the remainder of a network canoften still function with the failure of any single node. However, it must be noted thatring topologies limit the aggregate bandwidth of all communication on the networkto the signaling rate on any link (1 Gigabit per second).

In a switched network the aggregate data flow is only seen in the switch. Datacan be selectively routed6 between nodes that have identified a requirement for thedata. Each individual segment of the network is limited to GigE speeds, but thespecialized routing hardware inside the switch can handle much higher aggregatedata flows, typically several multiples of the link data flow. As a result, an individualimager is limited to 1 Gigabit/second to the switch, but multiple imagers can beaccommodated with a much greater combined output. In a similar manner, individualcrew workstations are limited to selecting combinations of video feeds that combineto less than 1 Gbit/second, but each workstation user can select the video image(s)appropriate for their task within that limit.

Fault tolerant operation of a switched data network requires replication of the switch.This concern is addressed in Section 3.3. The ADVANCE project has selected andrecommends the use of a switch-based topology for video transfer.

6Selective routing uses techniques such as multicast and virtual local area networks (VLANs),which are both commonly available in commercial switch implementations.


3.2.3 Video compression

Video compression techniques can be used to reduce the bandwidth requirement foran individual image source. This can allow a given network to operate with moresources and allows versions of the image stream to be transferred on wireless networksor links that have insufficient capacity to transfer uncompressed imagery. Numerouscompression techniques are available and in common use; however, the impact ofcompression on task performance needs to be understood before it is applied.

Common compression techniques add latency in the display of the image to a crewmember. The latency achieved can be a factor of both the compression techniqueand the way that it is implemented. Some compression techniques operate on eachvideo frame as an independent image and others use sequences of frames. Multi-frame compression techniques can achieve much higher compression ratios throughexploiting the similarities between frames in a sequence; however, these techniquesalso entail more latency, as multiple frames are buffered for analysis before beingtransferred.

Video compression can also reduce image fidelity; removing detail from the imagethat may be important to target perception and identification. Most video compres-sion techniques derive from commercial standards developed for photographers andcinematographers. Avoidance of perceptible image artifacts is of primary importancein this market, and rigorous image fidelity is not guaranteed. As a general rule,compression techniques reduce the high frequency detail in the imagery. This canresult in the suppression of contrast for small objects, which may, in turn, reduce theeffective detection range of an imager where compression is used. As a result, it isdesirable to use uncompressed imagery for weapon sights. Most other tasks withinan AFV can be performed with the image fidelity associated with moderate levels ofcompression; however, the induced latency must still be considered.

3.2.3.1 MJPEG / MJPEG2000

MJPEG is a composite acronym for Motion JPEG (Joint Photographic ExpertsGroup). It refers to a type of video compression where each frame of a video stream iscompressed individually, using the JPEG compression algorithm. JPEG compressioncan be tailored to trade off the size of a compressed image with a resulting imagesize. As a general rule, JPEG compression techniques (in common with most othercompression methods) reduce the high frequency detail in the imagery. Frame byframe compression can be implemented with relatively low latencies, between 1 and2 frame periods (16 to 30 mS for 60 Hz imagers)

MJPEG2000 is a very similar technique using the more recent JPEG 2000 compres-sion algorithm on individual frames. The JPEG 2000 standard is captured as ISO


15444 and is more tightly specified than the original JPEG standard. It is generallyaccepted to provide slightly better image quality for a given compression ratio andincludes an option to achieve lossless compression7 – albeit at very small compressionratios. Industrial support for MJPEG 2000 encoders and decoders (often referred toas “codecs”) is widespread, but not as ubiquitous as support for JPEG.

Achievable compression ratios with JPEG or JPEG 2000 compression, are determinedultimately by the use for the imagery. For driving and for general situational aware-ness, a compression of 10:1 should be achievable without introducing artifacts thatare distracting to those uses.

3.2.3.2 MPEG-2

The MPEG-28 codec (ISO 14496) is broadly used and has seen service in the CAFfor streaming video applications. It is a multi-frame encoding method. Many imple-mentations of MPEG allow for video streaming at fixed data rates with the quality ofthe decompressed image varying depending on the complexity of the scene. Variablebit rate implementations are also available where the image “quality” is consistentbut the transmission rate changes. Implementations of MPEG-2 exist that providelatency values of under 100 mS; which can be consistent with the requirements forsome vehicle tasks.

MPEG-2 compression should be able to deliver compression ratios better than 20:1for general situational awareness tasks. It is not clear that the latency associated withcommonly available MPEG-2 codecs would be compatible with driving requirements.

3.2.3.3 MPEG-4 / H.264

The MPEG-4 codec (ISO 14496) is very broadly used in the surveillance, satelliteand digital cable video distribution fields. It is a multi-frame technique and generatesvery high compression ratios; however, it may not provide suitable latency for vehiclenetwork applications. End-to-end latencies routinely exceed 500 mS. This makes thetechnique unsuitable for most vehicle tasks. MPEG-4 typically provides substantiallyhigher image fidelity for a given transmission bandwidth than its predecessor format(MPEG-2), so the format may have significant value to compress video for transferoutside the vehicle.

The H.264 video compression standard (defined by the International Telecommuni-cation Union – ITU) is a compression standard related to MPEG-4 and in most

7Lossless compression ensures that the processed image after decompression is an exact replicaof the original image.

8Motion Picture Experts Group


implementations exhibits similar latency. Some vendors have demonstrated cus-tomized implementations of this codec with lower latencies, accepting reduced com-pression ratios for lower latencies. This may be a valid option for applications wherehigher compression than that achievable with frame-by-frame methods is required(i.e. MJPEG2000), however, this avenue has not been explored sufficiently withinADVANCE to make a definitive recommendation.

3.2.3.4 Enhanced Compression Wavelet (ECW)

The Enhanced Compression Wavelet codec was developed for remote sensing appli-cations. It compresses single frames, and the definition provides options to processpartial frames. This allows an implementation to begin compression and data trans-fers before the entire image is available from the imager; allowing reduction of theend-to-end latency. The format also has different loss characteristics than the JPEGformat (with less suppression of fine detail), which could provide for better targetdetection and identification in compressed imagery. The ECW codec has much lesscommercial acceptance than the MJPEG or MPEG variants, but it has sufficientsupport to remain a viable candidate.

3.2.3.5 Recommended compression options

Video compression is a rapidly evolving field, much of which is implemented in soft-ware implementations that can be replaced or maintained as required. Generic sup-port for video compression in the architecture is highly desirable. Support for theMPEG-2, H.264 and both the MJPEG and MJPEG 2000 codecs is recommended forcurrent implementations.

3.2.4 Protocol

As in the case of the control layer, a protocol specification is required to coordi-nate data transfer. Two protocols are in common use over Gigabit Ethernet, GigEVision R⃝(GEV) and the Real Time Protocol (RTP). Both protocols are included inthe specification of the draft NATO STANAG 4697 Platform Level Extended VideoStandard which has been distributed for consideration by the Land Capability Group2 on Combat Manoeuvre.

The RTP protocol definition identified in the proposed STANAG is fully described bythe United Kingdom Defence Standard 00-82 entitled “Digital Video Distribution”(UK Def Stan 00-82). This document, in turn, references several Request for Com-ments (RFC) publications released by the Internet Engineering Task Force (IETF).These RFCs are effectively interim standards for internet protocols. The proposedSTANAG extends this definition to include other multimedia protocols, primarily tosupport voice data transfers. The underlying RTP standard has seen broad use in


the surveillance video industry, primarily in applications where video is transmittedafter compression by an MPEG-4 method.

The GigE Vision R⃝ standard was developed and is maintained by the AutomatedImaging Association. The GEV standard was developed for the machine vision in-dustry, and is significantly less complex than the RTP based standard. GEV is widelyused in the machine vision sector, primarily in the transfer of uncompressed imageryfor machine vision applications such as automated inspection, while the GEV protocolprovides extension to support the transfer of compressed imagery, however, compre-hensive support for compression has only been included in the most recent version ofthe standard9 and the depth of product support is not yet apparent. The proposedNATO STANAG reference the GEV standard directly, in conjunction with anotherdocument [1] that provides implementation guidance in respect to the application ofthe GEV standard in combat vehicles.

Both the GEV and the RTP standard (as extended in UK Def Stan 00-82) include“in-band control” capabilities. This means that any configuration or control of theimager can be routed through the main data cable, so that no other interface to theimager is required.

There are few technical concerns or constraints that would motivate a preferencebetween the GEV and RTP video transport protocols. The most demanding visiontasks in a combat vehicle (target acquisition and driving) require low latency imageryand image fidelity is is especially critical for target acquisition. Uncompressed imageryprovides the best option for both of these applications. This is well supported byindustrial experience and product in the GEV market.

The ADVANCE project has selected and recommends the GEV protocol primarily onthe basis of the available product supporting uncompressed video transfer, combinedwith the quality and quantity of industrial support for the protocol. The machinevision community that developed and maintains GEV targets primarily low volume,high performance imaging applications with extended life-cycle support requirements.Significant numbers of high performance imagers are available that are compliantwith the GEV standard and engineering firms exist in the machine vision marketthat provide expertise to customize existing or new imagers to the GEV standard.As noted, the RTP standard is widely used in the surveillance market, but tends tobe employed in lower cost, high volume installations with routine use of compressionto reduce networking and video storage costs. The parallels to the defence marketand the machine vision market are better, and it is expected that the support forimplementations with demanding technical constraints will be more readily available.

9Version 2.0, approved by the GIgE Vision technical committee on 10 November 2011


3.3 Information layerA combat vehicle has other networking requirements beyond low latency video andcontrol. Support for transferring map data, still images and compressed video streamsare also required. Analysis of these requirements indicates that the overall bandwidthrequirement is relatively modest in comparison to the requirement for the video layer.The bandwidth demand is mostly driven by requirements to stream compressed video.If high definition sources are used, even compressed video can be a demanding net-work load; HDTV compressed with MJPEG techniques would likely still require abandwidth allocation on the order of 50 megabits per second. Other bursts of datatransfers will occur in response to individual operator requests. Generally, the “infor-mation layer” supports all of the unmanaged and lower priority data transfers. Whileall of the tasks in a combat vehicle are designed to contribute to mission success, notall have the same, real-time, imperative that characterize the imaging supported bythe video layer network implementation. Implementing the information layer as a log-ically independent network allows the clear separation of intermittent data transfersfrom the video data that requires a guaranteed level of performance.

From a hardware perspective, both the video layer and the information layer require-ments can be met with identical hardware. Modern Ethernet switches allow the sep-aration of individual network connections into segregated virtual local area networks(VLANs) which do not share any traffic. As a result, two completely independentVLANs one supporting video data transfers and one supporting information trans-fers can share the same physical switch device. While a single switch is possible, it isrecommended that any installation in a combat vehicle implement a minimum of twoEthernet switches. By selectively connecting image sources to alternate switches andconnecting crew workstations to both switches, one can construct a network designthat will maintain partial system operation in the event of a network switch failure.

3.4 Secure layerWhile the vast majority of traffic within a vehicle has limited or very transient sensi-tivity, there will be times when commanders of individual vehicles will need to haveaccess to information with significant security constraints. To support this require-ment it is desirable to have a limited subset of the vehicle network associated with theoff-board communications equipment that is fully qualified to support secure traffic.Furthermore, the current selection of radio equipment selected for the Land Com-mand Support System in the near to medium term is designed to support securetransmission and incorporation of a secure data access capability is assumed.

The implementation of a secure network capability at a hardware level requires rela-tively arduous design, testing and certification processes, so the extent of this networkshould be carefully contained. Casual extension of the secure network to the broad


range of intelligent systems hardware embedded in a modern vehicle invalidates theunderlying security design and would likely compromise any certification process.

Qualified hardware and software solutions exist to allow controlled data transfer be-tween a secure network and an unclassified network, based upon predefined data types(or data objects) that embed information sensitivity identifiers. The data objects thatare intended to be transferred must be preselected to allow the transfer “device” toinspect the structure and security designation to ensure that data is only passed thatis intended for transfer as part of the defined security criteria. Data transfer from thelower security network to a higher security network is generally not an issue from apolicy perspective; however, care must still be taken to ensure that the transfer cannot be used to inject malicious software10 into the secure network segment.

Information transfer from a secure network to a less secure network presents a muchmore fundamental problem. Information transfer should be explicitly authorized onthe basis of knowledge about the sensitivity of the data object and its contents. Forsimple data types it may be possible to designate the data on a fully automatic basis.As an example, it may be desirable to transfer an unannotated geographic positionfrom the secure network to the vehicle network to control the pointing direction ofa sensor or the weapon. With no potential to add context to the position value,it is plausible to consider marking this class of data object as unclassified withoutintervention. More complex data objects may require human intervention to ensurethat the information is unclassified or that any secure information is redacted. Dataobjects that are intended to be subject to potential transfer must incorporate securitytags to signal the security level of the data.

Existing transfer solutions fall into two broad categories - “data diodes” that supporttransfer in one direction only, or “guards” that can be configured for bi-directionaltransfers. Guards are a much more flexible solution and more appropriate to sup-porting the functional requirements of an AFV. Guards can be implemented as astandalone network device, or guard functionality can be integrated into a generalpurpose computer that is designed to support the functionality.

Recent developments in software partitioning (e.g. MILS – multiple independentlevels of security) allow a common computer display11 to be used to display andinteract with information with differing levels of sensitivity within a single computersystem. This can allow designated crew workstations to support access to securedata as a subset of their primary role in fighting and operating the vehicle. On itsown, MILS software does not provide any route to transfer data other than through

10Executable code, executable code fragments, or improperly formed data objects that result insoftware failure.

11The underlying hardware design must support the desired software partitioning, so the softwaremay require hardware designed explicitly for the technical requirements of MILS software.


operator reentry, although cut and paste functions may be enabled. As a result,it should be considered as only part of a solution that addresses automated datatransfers through a guard.

The ADVANCE project implemented and recommends the inclusion of guard func-tionality between a secure network and the vehicle network, where the secure networkis constrained to be as small as possible – including solely the secure radios, voice/au-dio interconnections to the radios, and at least one display. The display connected tothe secure network should be specified to allow the installation of MILS software toallow the greatest flexibility in its use. While vendor solutions including the guardfunctions within a MILS display are proposed, it is recommended that near term im-plementations implement guard functions on a standalone processor to reduce risk.This allows the guard function to be validated and verified completely independentlyof other software.

3.5 Rotary base junctionsMost combat vehicles incorporate some form of rotary base junction (RBJ, also knownas a slip ring) that allows power and data to be transferred from the base vehiclechassis to a turret that is capable of continuous rotation. The “turret” may be aconventional manned turret, or an unmanned turret / remote weapons station. Inany instance of this, the turret will generate imagery and, in a manned turret, theturret crew will require access to imagery that originates in the hull. As noted above,transferring high fidelity, low latency image data requires relatively high data rates,even with compression. As a result it is recommended that this issue be considered inthe selection or specification of RBJ capabilities in CAF vehicles. Fibre optic rotaryjunctions (FORJs) are readily available from a variety of commercial sources andare currently installed in the Coyote fleet. These systems provide a simple solutionto directly transferring gigabit data rates between the hull and the turret. Whileintegration of a FORJ requires a minor level of engineering effort, the component costis not high. A recent quote for a single, dual channel FORJ exceeding the specificationof that used in the Coyote fleet was under $4,000 CAD. Costs in production quantitieswould be less than that.

3.6 Summary of objective architectureA pictorial representation of how the architecture would integrate into a combatvehicle is included as Figures 1 and 2, where one depicts the turret components andthe other the components in the hull. The complexity is based on that required fora vetronics equipped LAV III infantry fighting vehicle; however, it is similar to thatrequired for any turreted vehicle that is not used in a command post role.


Figure 1: Representative example of objective architecture (Turret).

Figure 2: Representative example of objective architecture (hull).


As shown, it is assumed that the vehicle would have five image sources in the turret(weapon sights and independent commanders sight) and six in the hull (driving andnear field situational awareness). The detail on the control network is very sparse,generalizing all of the potential functionality into generic “CAN controllers”. A realvehicle implementation might have many more systems and sub-systems connectedto that bus.

The video and information networks are shown as separate networks, but, as notedearlier, it is recommended that the connections to the Ethernet switches be intermixedso that the vehicle could still be fought and manoeuvred in the event of a networkswitch failure.

It should be noted that there is an implicit assumption that a version of the CSB(communication selector box) hardware/firmware could be developed that alloweddesignation of audio streams (embedded labelling) with respect to their security –based upon the net selection switch position. This would allow voice streams fromthe vehicle crew to be routed over the guard to the less secure vehicle network asrequired.

3.7 Related national programmesCanada is not alone in defining vehicle requirements that adopt a common architec-ture to lower future integration risks and to control costs. Numerous architecture def-initions have been developed by other NATO countries, including the United States,the United Kingdom and France. These architecture definitions have a great dealof fundamental commonality and in many instances could share common hardware;however, they do differ in some details. The differences between the architecturedefinition included herein and those of other national programmes are summarizedin Table 4.


Table 4: Related National Vetronics Architectures.

Nation Program Name Differences with ADVANCE StatusUnited Generic Vehicle Includes additional safety Def Stan developed

Kingdom Architecture (GVA) critical layer, different for FRES Scoutprotocol for video. Single acquisitionsecurity level

United VICTORY No integration of target Formal specificationStates acquisition imagers or published August 2011

weapon aim point (US Only to date)France Integrated Modular Merges Video, Information Field demonstrator

Vetronics (IMV) layer and Voice on single contracted to Nexternetwork layer under BOA program


4 Conclusions

Current expectations for vehicle capabilities are driven by goals for survivability,firepower and situational awareness that have risen sharply as a result of recent op-erations. The Army is acquiring new vehicles and upgrading segments of the currentfleets to address these goals; however, it is unrealistic to expect that these vehicleswill meet all expectations as delivered. Significant integration of communications andcommand and control equipment are still required, and life cycle management to planfor upgrades and obsolescence mitigation needs to start rapidly.

Acquisition constraints within the Family of Land Combat Systems (FLCS) programprecluded direct specification of a common architecture, so opportunities for com-monality and fleet wide integration strategies are reduced – yet they still exist. TheArmy has an opportunity to move forward, exploiting the concepts of common systemof systems architecture to minimize fleet maintenance, upgrade and deployment costs– even if the underlying vehicle systems are more disparate than desirable. It is verylikely that many of the design practices in the vehicles being selected for the FLCSwill be sufficiently similar that very significant cost efficiency can still be derived bysharing integration strategies and solutions.

At a minimum, this should include an ongoing commitment to coordination of vehiclearchitecture documentation as vehicles are acquired to allow every opportunity forrationalization of engineering effort as platforms are integrated with common CFsystems for communication and command and control. As vehicles are fielded, aconcerted effort to coordinate interfaces, data formats and protocol conventions usedacross the fleet will better equip the platforms for interoperability and allow at leastsome of the effort to be shared.

Consideration should also be given to the establishment of a design authority for theoverall land combat system, to explicitly link the technical capabilities and require-ments for individual platforms to the capabilities of all platforms in the combat team.This would consolidate the interpretation of the concept of operations for future com-bat teams into definitive data exchange requirements: including what data needs tobe exchanged; how often (and how quickly) the data needs to be transferred; and whoneeds what data to enable the combat effects desired. This effort needs to carefullyconsider data priorities to cope with both best case scenarios, when all of the com-munication links are fully operational, and degraded modes where communication issporadic or bandwidth is limited.


List of acronymsADVANCE Advanced Vehicle Architecture for a Net-enabled Combat Environ-

ment

AFV Armoured fighting vehicle

AIA Automated Imaging Association

BOA Bulle Operationnelle Aeroterrestre

BWB Bundesamt fur Wehrtechnik und Beschaffung

CAE PS CAE Professional Services

CAN Controller Area Network

CF Canadian Forces

CUP CAN Utility Protocol

DRDC Defence Research and Development Canada

ECU Engine Control Unit

ECW Enhaced Compression Wavelet

FLCS Family of Land Combat Systems

FORJ fibre optic rotary junction

FOV field of view

FRES Future Rapid Effects System

GDC General Dynamics Canada

GEV GigE Vision R⃝

GigE Gogabit Ethernet

GVA Generic Vehicle Architecture

HDTV high definition television

IEEE Institute of Electrical and Electronic Engineers

IETF Internet Engineering Task Force


IMV Integrated Modular Vetronics

ISO International Standards Organization

ITU International Telecommunication Union

JPEG Joint Photographic Experts Group

LCG Land Capability Group

LCSS Land Command Support System

LSAS local situational awareness system

MILS multiple independent levels of security

MJPEG Motion Joint Photographic Experts Group

MOTS military off the shelf

MPEG Motion Picture Experts Group

NATO North Atlantic Treaty Organization

NRE non-recurring engineering

PoE power over Ethernet

QoS Quality of Service

RBJ rotary base junction

RFC Request for Comment

RPM revolutions per minute

RTP real time protocol

SAE Society of Automotive Engineers

STANAG Standardization Agreement

TDP Technology Demonstration Project

TTP tactics, techniques and procedures

USB Universal Serial Bus

VLAN virtual local area network


References

[1] Chesney, R. H. (2009), Use of the GigE Vision R⃝ Imagery Transport Standard inAFVs, (DRDC Suffield Technical Memorandum TM 2009-290) Defence Researchand Development Canada – Suffield.


DOCUMENT CONTROL DATA(Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated.)

1. ORIGINATOR (The name and address of the organization preparing thedocument. Organizations for whom the document was prepared, e.g. Centresponsoring a contractor’s report, or tasking agency, are entered in section 8.)

Defence Research and Development Canada –SuffieldPO Box 4000, Station Main, Medicine Hat, AB,Canada T1A 8K6

2a. SECURITY MARKING (Overall securitymarking of the document, includingsupplemental markings if applicable.)

UNCLASSIFIED

2b. CONTROLLED GOODS

(NON-CONTROLLED GOODS) DMC AREVIEW: GCEC June 2010

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriateabbreviation (S, C or U) in parentheses after the title.)

ADVANCE Technology Demonstrator

4. AUTHORS (Last name, followed by initials – ranks, titles, etc. not to be used.)

Chesney, R.

5. DATE OF PUBLICATION (Month and year of publication ofdocument.)

August 2012

6a. NO. OF PAGES (Totalcontaining information.Include Annexes,Appendices, etc.)

56

6b. NO. OF REFS (Totalcited in document.)

1

7. DESCRIPTIVE NOTES (The category of the document, e.g. technical report, technical note or memorandum. If appropriate, enterthe type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period iscovered.)

Technical Report

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development –include address.)

Defence Research and Development Canada – SuffieldPO Box 4000, Station Main, Medicine Hat, AB, Canada T1A 8K6

9a. PROJECT OR GRANT NO. (If appropriate, the applicableresearch and development project or grant number underwhich the document was written. Please specify whetherproject or grant.)

9b. CONTRACT NO. (If appropriate, the applicable number underwhich the document was written.)

10a. ORIGINATOR’S DOCUMENT NUMBER (The officialdocument number by which the document is identified by theoriginating activity. This number must be unique to thisdocument.)

DRDC Suffield TR 2012-048

10b. OTHER DOCUMENT NO(s). (Any other numbers which maybe assigned this document either by the originator or by thesponsor.)

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by securityclassification.)( X ) Unlimited distribution( ) Defence departments and defence contractors; further distribution only as approved( ) Defence departments and Canadian defence contractors; further distribution only as approved( ) Government departments and agencies; further distribution only as approved( ) Defence departments; further distribution only as approved( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspondto the Document Availability (11). However, where further distribution (beyond the audience specified in (11)) is possible, a widerannouncement audience may be selected.)

Unlimited

13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highlydesirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of thesecurity classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It isnot necessary to include here abstracts in both official languages unless the text is bilingual.)

Recommendations for the introduction of a common electronic architecture for Canadianarmoured fighting vehicles are made, based on the outcome of studies, laboratory testingand hardware integration trials conducted under the Advanced Vehicle Architecture for aNetenabled Combat Environment Technology Demonstrator Project (ADVANCE TDP).Technical require-ments are derived from an analysis of operational requirements based oncurrent operational capability requirements and forecast future requirements.

An objective architecture is defined based on readily available commercial standards andintegration methods to best meet the technical requirements. The use of system-of-systemsengineering practices to apply common architecture concepts to exploit commonality in offthe shelf platforms is recommended to coordinate all aspects of life-cycle engineering frominitial fielding through major upgrades.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and couldbe helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such asequipment model designation, trade name, military project code name, geographic location may also be included. If possible keywordsshould be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified.If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

Vehicle ArchitectureVetronicsTDPAFVSystem IntegrationADVANCE

Des recommandations concernant l’introduction d’une architecture électronique commune aux véhicules de combat blindés canadiens sont faites et sont basées sur le résultat d’études, d’essais en laboratoire et d’essais d’intégration de matériel effectués dans le cadre du projet de démonstration de la technologie d’architecture de véhicule avancée pour environnement de combat réseau-centrique (ADVANCE TDP). Les exigences techniques découlent d’une analyse des exigences opérationnelles basées sur les exigences de capacité opérationnelle courantes et sur les exigences prévues.

Une architecture objective est définie sur la base des méthodes d’intégration et des normes commerciales facilement disponibles pour respecter le mieux possible les exigences techniques. L’utilisation de pratiques techniques de système pour appliquer des concepts d’architecture commune pour exploiter le caractère commun des plates formes standard est recommandée pour coordonner tous les aspects de l’ingénierie du cycle de vie de la mise en service initiale jusqu’aux mises à jour importantes.

Defence R&D Canada R & D pour la défense Canada

Canada's Leader in Defence and National Security

Science and Technology

Chef de file au Canada en matière de science et de technologie pour la défense et la sécurité nationale

www.drdc-rddc.gc.ca

Documents

ADVANCE technology demonstrator · 2016. 12. 5. · dian armoured fighting vehicles are made, based on the outcome of studies, laboratory testing and hardware integration trials conducted