A Short Story of Military IT-security evolution and Map of Roads it has left behind

WHAT IS MILITARY IT-SECURITY?

Information Technology Security (IT Security) is information security applied to computers and computer networks. Information security is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction. Information in this case includes all its forms from data to knowledge. All this can be defined as it is done in ISO 27000:2013: “Preservation of confidentiality, integrity and availability of information whilst taking care of authenticity, accountability, non-repudiation and reliability”. 

Information has to have these dimensions of security quality as illustrated in fig 1:

Confidentiality, which is preventing the disclosure of information to unauthorized entities.

• Data confidentiality is preserving authorized restrictions on data access and disclosure.
• Privacy assures that individual control of influence what information related to them may be collected and stored and by whom and to whom that information may be disposed
• Authenticity is the confidence in the validity of a transmission, a message or a message originator

Integrity, which is the accuracy and consistency of information thorough its entire life-cycle.

• Data integrity assures that information and programs are changed only in a specific and authorised manner.
• System integrity assures that system performs its intended functions in an unimpaired manner.
• Accountability assures that actions of an entity can be traced uniquely to that entity. 

Availability, which means that information and its processing services are ready for and in use of authorized users when they so require.

Figure 1: Classical structure for IT security

IT security is built with layered structures of technical (hardware, software and communications) security, physical security, personal security and organizational security measures.

This paper does not refer to embedded computing but to military utilization of commercial computing devices and their security measures. Thus technology roadmap begins not from Polish Bombe machine that they used to decrypt German Enigma coding but with mainframe computing (1964 IBM System/360 was market leader ) utilized for military resource management, statistical calculations and human resource management . From this on military IT security has tried to sustain mainly confidentiality and keep up with exponentially increasing technological complexity of computing and datacommunications.

WHAT IS IT SECURITY BASED ON?

Information management has been passed on printed mediums since Gutenberg revolutionized the management of explicit knowledge about 1455 by printing first Bibles. Before that information was mainly tacit. Cambridge University Library had 1424 only 122 books . Gutenberg changed totally information management procedures and at height of this era when 2009 the number of books in English in Nielsen BookData catalogue was over 8 million .

Books has been stored in library and their reading has been controlled by librarians since famous libraries of Nineveh and Alexandria. This has created the very basis for information management and thus information security. Books, their publication and copyright system has taken care of information integrity. Books have been available in libraries and librarians have controlled who were reading them. 

Figure 2: Gutenberg, library and human tendencies from information security point of view

Human beings are naturally curious. Through exploration and investigation they learn from their discoveries. They also have tendency to collect items like books sometimes over exceeding their actual need to read them. To counter this behaviour confidentiality has based on restricting people to get their hands on books that contain sensitive or unapproved information. Library has been physical site where both confidentiality and availability has been maintained. Books are available but their reading is under control.

People has also tendency to choose the path of least resistance. This is specially studied in information science. Information seeking client will tend to use the most convenient search method. Information seeking behaviour stops as soon as minimally acceptable results are found. Thus people have tendency of bypassing any security control if that demands fewer effort than following security procedures. 

The history of information management is based on physical structures of libraries that constraint users access to information managed in books, shelves, catalogues and bibliography. Librarians have been in key roles to project security policy by creating bibliographies of books and their authors, storing them in shelves, rows and rooms with classification system and further logging books and their loaners.  This was the legacy structure that has defined the early years of information technology security measures.

TRUST ON PHYSICAL STRUCTURES

Very first Mainframe computers were installed in closed rooms sheltered preferably underground to create multi-layered physical security specially to control access of human beings into computer services and digital information. Human beings and printed information were considered main avenues for information breach thus computerizing was not considered a specific risk as illustrated in fig 3.

Figure 3: An example of classical site structure based security trust 

Data communications was not considered since information feed to mainframe and outcome was mainly via punched cards. Later when terminals were introduced it was estimated that risk of someone tapping special wiring with right code breaker was non-existent.

Printed documentation was categorised, labelled and kept within buildings and inside vaults. Problem occurred when documents were transferred between sites. This risk was countered with online data communications encryption devices which were evolved from history of online communications security starting from Green Hornet during WWII. Printed documents from trash bins, mail and couriers were main points of intrusion for outsider to get documented information. Most information was captured by insiders  or with evolving telecommunication technology through social engineering  and telephones. Human Intelligence was adversaries’ main method.

During 1985 studies relieved that computers were transferring unintended electromagnetic waves which could have been received outside of trusted physical site. To control emission the TEMPEST standards (a minimum of 100 dB insertion loss from 1 KHz to 10 GHz) were invented and computers were installed inside Faraday shield. All electromagnetic emission is cancelled in conductive wall material of this structure (usually metal) and no emission is leaked through cage. 

There are many different categories for physical security but one generic is as depicted in fig 4:

1. Level perimeter: required to process top secret information
2. Level perimeter: required to process secret information
3. Level perimeter: required to process confidential information
4. Level perimeter: required to process restricted information

Figure 4: Generic classification of physical security in military compounds

These perimeters are normally built within each other so outer shield protects inner. In typical military compound outer fence with access control by gates and either security personnel or electronic systems based surveillance provides 4th level perimeter. 3rd level security perimeter is achieved when inside 4th perimeter there is building or shelter that has separate access control and structure that prevents other avenues of access. Consequentially 2nd and 1st perimeters are inside 3rd with separate access management and additional protective structures. During peace time these structures may be design to prevent physical breach until reactionary forces arrives to capture intruders. When war time structures are designed, survivability under attack is the greater goal.

Still one finds that computers in within 1st perimeter are often offline and accessible only to personnel who have physical access to top secret facilities. These computers are unfortunately weak when it comes to resist cyber threats over air cap as it has been demonstrated in cases of Stuxnet and Agent.ptz (latety version SNAKE). 

TRUST BASED ON CONTROLLABLE DOMAIN PERIMETER

As information management includes dissemination of information at least need-to-know bases, there was the need to connect secure physical military sites to other similar. This was established by having improved communication security on the lines that were used between computes in physical shelters as defined in fig 5.

Figure 5: An example of IT security that is based on trusted domains

Encryption started at very low level of datalink layer 2 or similar within line modem devices. With Ethernet protocol at Local Area Network and several Wide Area Network link structures encryption struggled to provide both performance and cryptography required. Digital COMSEC at layer 2 has evolved from preISDN 64 kpbs online devices and 2 Mbps PDH trunk encryption devices to current GigaEthernet encryption solutions that are either embedded into switches and routers or build in separate devices. Since physical security was structured as onion, also COMSEC was defined to follow the familiar one inside the other -structure. If layer 2 encryption did equal perimeter 4, then additional layer 3 encryption was good for perimeter 3 and additional layer 4 encryption was equalling perimeter 2 domain. 

So more and more data transfer capability was utilized to encrypt IP-packets at different layers. There was not much sense making utilized on how much risks really was mitigated with this layered encryption but it was utilized since it was available and familiar way to solve security problems. One example of this design is illustrated in fig 6.

Figure 6: An example of COMSEC architecture in domain based IT security

Here basic level of extranet is protected by L2 encryption and together with physical perimeter they compose domain that ensures information management for restricted level. This extranet is isolated from outer world and especially from Internet threats by Aircap  defence. There might be other domains at this same level of security but since their control is with other authorities they are divided from rest or basic level extranet by OSI level 3 encryption and firewalls. This is typical when for example Air Force wants to keep their domain perimeter intact but utilize Armed Forces general network services.

Within basic domain there is the extended level security for management of confidential information. COMSEC is using layer 3 encryption called Virtual Private Network, (VPN) thus disabling all attempts to tap communications from lower level. There might also be one way only -gateway between restricted and confidential levels of security. This “diode” is used to transfer data via transactions from lower level to upper level of security but not to the other way. There are many attempts to build these one way only -gateways but their integrity remains always relational similarly as it is with the protection from Aircap isolation. Where there is a human being as a link in this chain of security, he will remain the most vulnerable for exploitation by an outsider.

Functionally structured military organizations have been building these system, service or organization unit based domains while sustaining their control, authority and self-defined development. “Need to know” information management policy spread out from operational level down to tactical level. NATO and US military organizations faced results of this tendency back 2009 when then ISAF Commader General Stanley McChrystal, seeing his force ineffectively trying to share information via “sneaker network” (manual download, transfer, upload procedure), called for better information sharing to counter networked adversary. Afghanistan Mission Network program and quest towards “share to win” policy was created 2010 to integrate numerous separate domains within NATO and within National force structures as described in fig 7. 

Figure 7: Example of attempts to solve multidomain interoperability while maintaining domain trust based security

Since then a massive gateway structure together with aligned security policies have been built to allow different systems to be used via one core platform: NATO Secret Mission Network. National domains are attached to this core by Network Interconnect Points (NIP) that are cross domain gateways allowing users from NATO secret level to access any secret level system provided by contributing nations. This enable the shared use of about 165 applications of which 55 were critical to mission.  Mission Network was finalized when important part, Network Operation Centre (AMNOC), was opened to enforce common policy throughout federated domains. 

Because of tight schedule to build up this core network it was done with a cost of inner security. First there was no defence structure inside NATO secret core but later monitoring and reaction based security structure was adopted from US NIPR network.  This had started 2006 and was called Host Based Security System.

TRUST BASED ON MONITORING AND REACTION CAPABILITIES

As the number of federated domains and number of nodes interconnected increased, perimeter based security policy doomed to be futile. There was something to be done behind high walls of domain perimeters to control security and react when malevolent incidents were detected. This is again very basic military tactics to survey larger space of operation and react with tactically positioned rapid reaction forces to counter any insurgency. Host Based Security System , HBSS was created in US DISA together with McAfee and BAE Systems, who were given the contract to implement first monitor agents to all hosts in network. All hosts that either process data or store it were provided with agents or equal function to produce required surveillance information to Security Operation Centre (SOC). SOC has control over IT Operations change management and configuration management and can quickly change configuration when malicious behaviour is detected from information environment as illustrated in figure 8. 

Figure 8: An example of Host Based Security concept by HBSS and McAfee

Basic principle is to define baseline or ‘whiteline’ of existing normal features within IT-domain. Special detectors are created to detect anomalies out of baseline patterns. When anomaly is detected, alert is forwarded to SOC, which creates security incident and starts executing countermeasures. Another approach is more proactive where security engineers are using Sandbox environment and penetration tools to test vulnerability of each ICT-component. Components are patched and hardened before released to operations environment. This process when executed continuously keeps Operational ICT up-to-date and as sustainable as possible. There are always failures in systems that are not remedied yet. They are called 0-day vulnerabilities. To compensate these vulnerabilities, special thresholds around these components could be installed to detect any attempts of exploitation.

Further host based security requires additional information from possible “honey pots”, systems outside cross domain gateways, that lure possible penetrators to capture their attack profiles. There is also a need to connect with larger society of cyber experts that continuously monitor malevolent behaviour in networks, collaborate and make better sense of incidents in networks as depicted in fig 9.

Figure 9: An example of Security Operations Centre concepts within Host Based Security

Explained Deterministic and statistic approach may be complemented with more heuristic surveillance methods. They are capturing full packets from both core and front switches and using advanced big data analyses tools over a vast amount of data. This enables to capture different attack profiles and silent trends.  

 

NEW CHALLENGES OF ZUCKERBERGIAN ERA INFORMATION MANAGEMENT

From Gutenbergian culture of information management there is a long leap to Zuckerbergian culture of information management as illustrated in fig 10. The amount of information is increasing faster than ever before, produced by both people and machines online. Text is replaced by pictures and videos just because it is easier and people can capture essential information from those better than from plain text.

Figure 10: A point of view that illustrates the change in information management from Gutenbergian culture to postmodern culture that Zuckerberg’s Facebook era represents

Data and information policies of Gutenbergian culture cannot keep up with emerging magnitude and speed of Zuckerbergian era. Book takes too long to write and publish. Web page, blog or wiki are much faster and more able to manage larger amounts of information between people. Data virtualization will change information sharing between Things in Internet. Internet can transfer more data than anything this far. It can connect billions of both people and Things to create intertwined man-machine systems.

Information security based on sites, perimeters or hosts is not able to scale to Zurkerbergian era amounts of information, where Facebook is extending by 210 terabytes (1E12) per hour and 20 % of users per year.  Even in military domain amount of data is increasing exponentially with image capturing. General Gartwright estimated that when DoD is evolving to cloud computing and mission network of Things, a military force in one operation is managing about one exabyte (1E18) of unique data in a month.  As thousands of sensors create new data continuously publishing it in computing cloud where huge clusters of HADOOP  file system (Facebook’s biggest Hadoop cluster is handling about 100 petabytes of data ) store it and provide it to analysing tools. It is clear that file, host or relational database based security cannot provide required confidentiality, integrity or availability of information for this data revolution.

SERVICE BASED SECURITY TRUST

Last attempt to provide IT security for exponentially increasing data is to collect it as fast as possible from sources whether they are people or technical sensors and store it into logically centralized datawarehouses. Large amount of data is closed within inner structure of “cloud computing” platform which is better controlled and data integrity and availability is more easily sustained. Confidentiality is based on user identification and role based access via application or presentation layer. This security structure is based on onion model of so called “defence in depth”, where network, host, application and data based IT security measures create integrated solution as depicted in fig 11.

Figure 11: Some principles of onion structure of IT security

When network society grows too large to be cost-efficiently monitored and behavioural baseline changes too quickly to recognize any normality, one has to once again gather all information to ‘libraries’ and create strict access policy and librarians to enforce it. 

There is no trust on end user devices thus their integrity has to be restored by compliance check and reconfiguration. To do this effectively the baseline of end user device has to be simple and configuration “thin”. Terminal has come back to vocabulary from late mainframe and early Unix era. Terminal is very thin client that may only remotely operate any complex applications merely by keyboard, screen and mouse.

There is no trust on access network so all sessions has to be encrypted over untrusted and in many cases roaming access networks. There might be Mobile IP solution that enables terminal to roam between available and cost-effective network connections and most often encryption is integrated into Mobile IP application. 

There is no trust on user names or single passwords but stronger identification is utilized. This may vary from smart card based token that includes secret key to biometrics based authentication like fingerprints, face picture, hand vessel picture or retina. User and Service needs bilateral authentication to create a temporary trusted session over untrusted environment. This requires bilateral authentication protocol to verify both entities. Often third parties offer certification authority services to both instances.

Since there is no trust on incoming terminal nor the communications protocol it is using nor the content it is proposing, a complex access gateway between service base and outer world is needed. These gateways include number of firewalls, demilitarized zones and interruptive proxies with content checking and filtering.

Within “Computing cloud” there are several layers of defence starting from very first portal and access management layer, where users are allocated to roles and roles have authorized rights to run applications and process data. This enables to manage hundred thousands of users categorised into thousands of roles and further allow access to applications and data content. This is called identity and access management. All subjects are under constant surveillance to detect anomalies and kill intruders before they are able to fulfil their operation. There are different gateways for man-machine sessions and machine-machine sessions to detect more easily different behaviours.

Applications may have structured aligned with Service Oriented Architecture where each function is requested via Service Bus and applications themselves may locate in different instances. This requires particular application identification and authentication structure within SOA platform.

There are many service based security services available in modern time Internet. Most eGovernance/smartGovernance or online Financial services are constructed in this manner. In military domain there are similar features to be found in NATO Future Mission Network  and DISA All Partners Access Network . Examples of service based security implementations are illustrated in fig 12.

Figure 12: Examples of service based trust structures in IT security

CONTENT BASED SECURITY TRUST

If we are living in a world where platforms and connections are changing swiftly, there is no longer single layer of trusted platform to be defined. Besides people there will be billions of Things connected to Internet both producing and processing data. Definable server will evaporate somewhere in software defined network and cloud.  SOA and Semantic web will disperse monolithic applications to distributed applets that form temporary functions according to requests of each processes. Text files will change to structured data with both format that machines can understand and metadata that ontologies can make sense of. Databases will be gradually virtualised first as loose structure of several databases but eventually to a datafabric stretched over whole cyber space where data items are addressed as we are now addressing web pages.

There is a possibility to lay trust structure around all the data items if they are restructured in semantic web way and equipped with metadata. Another base of trust is the user identity, which is tied to data items via 3rd party certification authority services. This enables sensitive data to be stored, processed, presented and transferred within untrusted ICT-platform while optimizing its assurance according changing situations. This may be called also software defined security . See fig 13 for examples of transformation and semantic web security structure.

Figure 13: Evolution of Information Technology and examples of content based security structure

One possible way to provide new structure for trust in content based security is described fig. 14. Availability is provided by distribution of resources since there is no guarantee enough for one node or centre to be available as required. This is typical especially to military environment. All entities in space should have a unique address with which they can be found and addressed. Every entity has to be authenticated based on strong identity. Tokens and biometry are already there for people but strong machine identification and authentication remains to be implemented.

There has to be logical structure both in data and applications to ensure that they are what they seem to be and functioning as expected. Each data content should be encrypted or signed to ensure data confidentiality and authenticity. There is a need to implement separate certification authentication and key management structure which is one base of authority and identity.

Figure 14: Example of trust structure in content based information security

Encryption key management is following the chain of authorization from user to assigned application, which is provided with needed key material to be able to process user required data. 

Applications of content base security are still rare, but one can find them within some cloud computing environment and at very tactical Battle Management System level.

IT SECURITY ROADMAP FOR MILITARY ENVIRONMENT

This study started from very basis of our information security based on tangible container of information, a physical location of information and authorized process in accessing information. Based on these structures of trust, military have been building gradually their digitalized information management and accordingly IT security from pure site based approach to controlled domain and further trying to monitor and control all possible hosts that either process, transfer or store information. Now military is facing a major leap in magnitude, speed and format of information and they are advancing towards service based IT security and have visions of content based information security.

Since IT security is not an asset itself but always a quality of existing information structure where both people, processes, information and technology are changing there is no ultimate end state in this technical roadmap that is illustrated in fig 15. Since IT security is based on risk management, there are some categories of information that are using more technically advanced structures whereas top secret information still remains on paper and is stored in vaults. Military have been last 10-15 years following civilian IT security measures where finance and commerce have been leading implementers. 

Figure 15: A roadmap for IT security within military environment

On this map there are different roads that military may choose based on their risk management, organizational, process, information and technology maturity. There is the basic path of SITE-DOMAIN-HOST-SERVICE-CONTENT, which has been followed in NATO and DISA structures. There has also been examples of successful journeys through other paths. Netherlands Armed Forces showed example early 2000 when they were promoting TITAN –structure for mission IT structure. Parallel with this program Finland was piloting their Transferable Operation Centre, TOC concept. Both of them left domain based security and went directly to service based security.

MultiNational Experiment –exercise has been developing Service based structure since 2006  for Crises Management operations in order to have all stake holders collaborating with each other in complex crises situations. Finland supported MNE 4 exercise with Shared Information Framework & Technology (SHIFT) that “demonstrated method to share information across various military, governmental and non-governmental information domains”.  

Finnish Defence Forces took path from domain based to service based between 2007 – 2012 in their national operational command and control support. FinDEF did change from site based 22 domains to one private cloud computing based service structure where information services were provided from restricted to secret. It was not fully successful since some parts of Defence forces were not as mature as others so there was not equal starting point to this journey but implementation server as a model for others to follow.

DISA operated networks improved their perimeter defence with host based security early 2006.  Afghanistan Mission Network went through transformation from very domain based structure 2009 to more flat and host based security by 2013. 

Finnish Land Forces are on their way from site based security directly to content based security with their next generation Battle Management System and tactical communications M18. 

There are plethora of references I have not included in this revision. Please ask a copy with references.

Lessons from developing Army Command, Control and Information System for Finnish Land Force during 2007 - 2009

This is a story of developing Army Command, Control and Information System, ACCIS for Finnish Land Forces. Development program was called MATI 2 (in Finnish MAavoimien TIetojarjestelma 2). This story is composed from personal observations of the author when he was the head of G6 and later inspector of signals between 2008 – 2012 in Army Command.

System engineering as development model

System engineering or V-model has been the main method in military systems development since 1950’s and famous especially from Apollo program. The model, which is depicted in fig 1, is originated from need to identify and manipulate the properties of a system as a whole rather than only properties of each part. This approach has been followed successfully to develop military systems, which has been integrated to force via manual processes. Problem has occurred when force integration requires machine to machine interoperability. Especially command, control and communications systems that has been creating a common bus for data exchange are facing development challenges. Defence vendors have legacy for closed architectures in the name of security, military coalitions are not flexible enough to define interoperability standards, fast evolving civilian information and communication technology is creating new pressures towards traditional military development and contemporary multinational operations have required quick solutions implemented during operation. Linear planning and investment driven development has been too slow to answer ongoing operations requirements.

Figure 1: Classical system engineering approach to development

This is a story of all good intentions to follow system engineering development model while mitigating risks by Commercial-Of-The-Shelf procurement, phased delivery via Initial and Full Operational Capability, special implementation of AQAP-quality measures and full involvement of functional, hierarchical organizations.

A short history of Army Command, Control and Information Systems in Finland

In 1994 there was the first field exercise in Finland, where main command post of an infantry brigade was connected by email service (VAXMAIL) to upper echelons. Common Operational Picture, COP was created still manually on paper maps and sheets of transparent plastic. Situational Information though travelled quickly by using digital messaging system, email or telefax. Orders were delivered verbally, written on paper and drawn on plastic sheet. Computers were used to help in creating documents, calculations and presentations within command post. Digital files were shared via Ethernet connections between offices, shared storages, closed email systems or by dispatchers with portable mediums.

In 1995 there was a field exercise where first Army Command, Control and Information System (ACCIS) was established and connected all the way from brigade command post to army corps and further to theater headquarters. It was called OPJO-95 (OPeratiivinen JOhtaminen), a Unix-based Graphical Information System (GIS) with virtual database to give processing speed, integrated message system to update COP -information and replication system that enabled transfer of larger amounts of data at time either on line or with courier. For first time Army orders were given on a digital map and delivered to subunits by electrical sheets over IP- or message networks. Typical Graphical User Interface (GUI) of Unix and even more complex GIS GUI made operator training time consuming and only very seasoned operators were able to beat “manual – pedal” planning and ordering system. This ended with situation where only those officers, that were forced to utilize system, possessed some skills to operate with it. Evolution of ACCIS in Finland is depicted in figure 2.

In 1997 artillery did use first time information system (JOHtamispaikkaLAitteisto, JOHLA-97) for their fire control centers. It was integrated with message system so forward observer (FOB) was able to send formatted message with messaging system -93 directly to JOHLA that presented fire command on digital map, calculated the position of FOB and delivered fire steering automatically to batteries. This really fastened indirect fires by removing human operators from calculation and signaling functions.

Figure 2: A short description of ACCIS evolution in Finland

The 2000 field exercise witnessed next generation ACCIS at every brigade level command post called JOTI JOhtamisen TIetojarjestelma). JOTI was a cousin of OPJO but with Microsoft GUI, easier graphical interface and it was running faster on a PC in each office of a command post. Staff work was accelerated by both office tools and GIS- system that enabled distributed working, cut briefing times half and squeezed planning time to one quarter from earlier. Since JOTI was integrated with message system all situational information was send in formatted messages to JOTI systems and semi-automatically presented in GIS-screens. Top – down development automated all COP –and Intelligence processes with brigade command posts but left lower echelons with manual maps and message terminals. Program failed to automate whole process from bottom up.

In 2005 JOTI update came up unsuccessful, sustenance of JOHLA-family ceased and Army Command had to make decision to downgrade their ACCIS to JOHLA-97, which had been updated without problems. Since functions were almost identical in both systems, there was no major issues in training. With sudden stop in their major ACCIS line (JOTI), Army Command was forced to initiate a program to procure and field next generation ACCIS called MATI 2 (MAavoimien TIetojarjestelma), since everyone understood that JOHLA-97 extension was only a temporary solution.

Initial phases of MATI 2 -development program

Army Command planned to have reasonably quick program to field next ACCIS called MATI. Since they did not have similar strong technical and tactical development force as was with OPJO/JOTI/JOHLA –family in early 90’s, Army Command decided to go after MOTS–product, which should have mitigated major risks of development. All national tactical requirements were changed to international since NATO –compatible was thought to be main driver at that time. National tactical symbols were changed to APP-6A and planning process was changed accordingly to NATO STANAG 2014. With Multinational Interoperability Program (MIP) there was also new datamodel for information exchange called C2IEDM (Command and Control Information Exhange DataModel). That was selected as a base for all datamodels in Defence Forces and Army Command required to follow model within the whole MATI-system.
Although MATI was planned to be bought as a turnkey solution mainly off the shelf, there was extensive planning and design work with field tests to capture primary requirements that all possible products would be tested against. Staff processes were changed to NATO compatible ones and they were role played and finalized as process documents to be utilize in further testing and training. Technical requirements were definite with Microsoft middleware platform, ability to operate standalone and within networked group over tactical non-IP communications. MIP –compatibility requirement was given from Joint –level and Service Oriented Architecture (SOA) was recommended although no specific requirements for open interfaces or structure were stated.

Possible vendors were screened with Request For Information –process that created lots of documentation produced from marketing point of view. Actual procurement process included Request for Proposals – Proposals – Prove of Concept – Shortlisting – Negotiation – Decision and contraction –phases. Prominent vendors were invited to intensive laboratory tests where both users and system administrators screened MOTS-applications. One vendor of Battle Management application (BMS) was chosen amongst many with good scores in usability tests and the only one that promised full MIP compliance with SOA structure. Major defence industry was either not able to provide functional system or they proposed old systems like existing JOHLA and JOTI.

Since chosen vendor was able to provide only BMS –application, a loose consortium was negotiated between application, communications and quality assurance providers. Joint level had created a theoretical model where 3rd party was utilized between customer and providers to help managing relations and deliverables. It remained unclear in contract structure, who was responsible of what deliverables and how they were approved. This model was new for all parties of consortium and customer. It was planned that application vendor provides off-the-shelf BMS-software to communications integrator, which in turn delivers BMS application with right communications configuration to customer. Because Defence Material Command had adopted AQAP -quality system, a 3rd party vendor was contracted only to do quality assurance.
Since this seemed straightforward linear procurement, customer distributed responsibilities in functional way as depicted in Fig 3. Material Command was executing procurement of Material parts supervised by G10 of Army Command. Army School was given testing and C3 processes development responsibilities. J6 did coordinate development with architecture, whereas C4I Centre did provide common components like Operation System, interfaces like MIP and XML gateways and joint level C3 system (LEIJONA). Defence University and R&D Centre were developing special functions supporting operational analyses. Everything was integrated by Inspector of Signals supported by G6 of Army Command, that also took care of other capability components of DOT(M)LPFII structure and prepared to field and operate the future system.

Figure 3: Distribution of responsibilities in MATI 2 procurement

Contract was signed for 2.5 years and deliveries were phased in iterative way: by the beginning of 2008 a integration version of BMS, by mid 2008 an Initial Operational version of both BMS and Communications and by the end of 2009 a Full Operational Capability versions to be fielded. Clear milestones and documented requirements to be fulfilled at time of delivery. This seems to be typical system engineering procurement and delivery project with responsibilities distributed to appropriate functions and risks mitigated by simple linear approach.

Challenges occur

Everything started well. All functions were in place and there was no big risk since BMS application was coming off-the-shelf. Contract was phased to three clear and measurable deliverables where all vendors had their own responsibilities. Funding was fastened for 3 years and risks were managed. Two important questions - WHY and HOW - were answered. But were they? 

Why this program was established and how shall it enable the capabilities of multiarms Battalion task force? Program was established to replace temporary BMS solution in Brigade command post and it was not planned to improve C3 processes or multiarms effect majorly. Sure all investment justifications were communicated within orientation for force digitalization and enabling awareness, but effectively there were no plans to extend BMS further than Battalion command posts, no plan how to integrate artillery, sappers, reconnaissance and surveillance or logistics processes into one system, no plan to integrate sensors or other awareness sources into system. From initial program intent project adapted only the simple task of replacing existing ACCIS.

How to integrate all layers together to create functioning system as defined in Fig 4? Only command post in Brigade had Local Area Network support. Battalions were still using analog radios and messaging system -93. Land forces was using their own messaging format that was not interpreted to MIP-datamodel. No one had an idea of how full synchronized BMS is able to replicate all necessary information throughout Brigade. There was no cross domain gateways (IEG) in between Land components and Joint C3 system nor were there any MIP-interoperable Joint C3 systems (LEIJONA) to be integrated to. No single model of the whole system either in small world installation or logical model was created to simulate and see how all these parts come together.

Figure 4: Technical challenges in ACCIS structure

Engineering logic was simple. If all these components were seen functioning separately, why should not they be easily integrated and function together. Unfortunately that was not the case!

Tactical communications challenges

As noted earlier, BMS was functioning over 100 M Ethernet between few nodes, but there was problem to fit replication traffic over existing Combat Radio Network. Communications integrator had assumed similar messaging as in older version of JOTI and JOHLA. BMS application session level required integrity of connection that messaging was not able to provide. Throughput of CRN digital channel was not near what was required by replication between BMS instances. Tactical IP connection with 128 kbps gross throughput was feasible but since Bit Error Rate was around 10 EXP-4 BER, the TCP-session was not stable enough for BMS client-server utilization. Application assumed fixed IP-addresses when mobility of command posts required changing addresses. Existing encryption was optimized for short messaging (32 bit block encryption) purposes and was not supporting continuous flow of longer IP-packets. 

At best tactical communications were useful if stations were fixed, running with maximum transmission and plain text. This was not what was required and communications integrator announced that project would need at least one year more and millions of euros additional resources.

Application developer was testing his system on LAN with very limited number of nodes. Communications integrator was honing existing messaging system with unrealistic assumptions. AQAP vendor did not understand this kind of system of systems development but concentrated merely in documentation transparency and governance.

Datamodel challenges

J6 had made architecture decision of adapting MIP information exchange model, C2IEDM and further JC3IEDM as a base for all Defence operational and tactical information management. They appreciated an idea of using one information model from soldier level up to Joint Command level since that would support best the transparency of common operational picture and provide interoperability for both national and international level. Decision was understandable from the view that MIP was the only information model development program running at that time, NATO indicated to adapt it fully and it was experimented successfully in exchanging COP information elements between nations CCIS entities.

Unfortunately no one had utilized model with larger force and with more exhausted replication. It appeared that application was not able to manage more than 2 000 to 10 000 units and thus was incapable to manage the whole Land Forces order of battle not to speak of Defence Forces. It also appeared that C2IEDM model implementation in relational database was using processing power extensively. Complex queries took long time to be executed within normal PC instance. C2IEDM replication protocol and policy was not planned to tactical communications thus introduced several errors and frequent disconnection from replication network. Replication was also meant to work between two instances which automatically restricted topology to a star. Even within Headquarters there was not possible to sustain longer than two level hierarchies in replication. Replication with three levels of hierarchy was not feasible.

C2IEDM as relational datamodel was not flexible for changes and did not understand recent features of operational space like NGO’s, supported population, communal administration, integrated effect of multiarms, jamming as fire element, etc. Datamodel took also long time to be established in first time. There was no practical way of cleaning old data but dumping whole system. If unit was not part of original Order Of Battle, ORBAT, it was impossible to add it on the run. All information was owned by troop that was part of hierarchical structure. Datamodel had problems to understand terrain, time or phenomenon based information. Datamodel was binding land forces tactics to international compromised understanding without national special features and did not support tactical adaptation or learning.

Testing challenges

There was no reference environment to test whole system of systems until it was installed for field exercise. This testing procedure did not detect main problems but until staff was employed in command posts and all vendors started parallel remedy onsite, which produced even bigger problems without shared knowledge of root causes. Everyone ended up frustrated and untrusting in each other’s capabilities and products. 

Several field tests were executed but not with same topology, ORBAT or situation, thus it was difficult to compare previous test results. There was also problem with staff officers using legacy procedures rather than NATO planning guide, GOP or Common Operational Picture fusing and sharing procedures. New SOP’s were not captured by testers, which produced one hand false expectations and other hand wrong perception of new system.

Basic performance and integration failures prevented test programs to proceed, which denied further feedback to developer. Challenges were managed more sequential than parallel, which did not give full picture of systems possibilities or challenges. Without laboratory environment and reference system there were no tools for gradual/parallel testing nor bringing in testing crew as technical issues matured. Lots of resources were lost in full scale field tests and MATI 2 got very negative brand value, which was further communicated by testers coming from different units.

Management challenges

Managing whole DOTMLPFII capability development was challenging since main focus was on material component. There was no aligned or coordinated plan to proceed with other components. G6 tried to come up with holistic plan, but major parts were missing. Army School did good job with staff work and BMS coordination, but Signal School was outside with their own agendas. A value chain of MATI 2 development and support organization is depicted in Fig 5.

Doctrine connection to tactical or C3 process development was nonexistent. Other arms were missed and most importantly intelligence, reconnaissance and surveillance was not included. The big Why was lost since initial commander’s intention was lost during haste execution and along many partially optimizing tentacles of functional organization.

Command post organization and C3 procedures were not really questioned although G6 tried to define major processes and published Land Forces C3 doctrine. There was a major mistake in attempt to adapt NATO based procedures and terminology as part of national art of operation and tactics. Outcome was long unsureness of used terminology and basic procedures.

Training focused only to have field exercise testers understanding of new processes and skills. Further fielding was not planned and education of new basic skills remained to be initiated. One should start to change basic tactical understanding amongst leaders for them to first understand WHY and then be able to instruct the HOW to troops when skills based training starts.

Even in material issues there were challenges since Material Command was not able to provide terminal devices for field use. C4I Agency failed to provide hardened operating system to field terminals. Since Joint operational C3 program failed totally, land forces were left alone without provincial above level C4-system to connect with and without necessary information services. Information Assurance solutions that C4I Agency proposed were not applicable in tactical environment. Even with best technical solutions off-the-shelf, there is no capability if understanding, integration and training skills of the whole system of systems are missing.

Leadership and management doctrine was still based on authoritarian and deep line organization without idea of emphasizing mission command or self-synchronized troops that would be able to swarm around adversary using terrain like infantry used to do during II WW. It was remarkable that conscripts and reservists adapted new tools and methods faster than enlisted, NCO’s and officers. It seems that learning new things and adapting new habits requires first unlearning of old things which takes both time and effort.

There was haste to build up required service support maturity within Signals personnel, since both technology, interconnections and system of systems interdependency required more Information Technology System Management, ITSM process approach than hierarchical line organization orders and control. If there is no legacy for process driven value chain like in artillery or logistics, then simple provider-client cooperation might appear hard to adapt by line commanded troops and their authoritarian leaders.

Maintenance and repair personnel were mainly sustaining individual devices that did not need software updates or complex configurations. Complex networked software defined systems required online warehousing, were all devices were powered and connected to maintenance network. Whole fleet of systems required weekly updates to keep interoperability and minimize vulnerability.

Information management was started to create and maintain training ORBAT for blue, neutral and red parties. Since there was a major delay at joint level C3 systems development, land forces were required to create alternative information feeds that provided weather forecast information, interagency Blue Force Track, BFT information, enemy target information from air and sea, logistics information from Defence Forces Enterprise Resource Management system, etc.

Interoperability required a standing Battalion task force reference system of fighting systems to be implemented. This reference was a small world where different experts and vendors met in integration testing, experimenting, system hardening, change management, root cause analyses and configuration management. The Reference environment sustained the integrity of complex interconnected system of systems and enabled quick changes when required.

Program management did have long hierarchical and administrative heavy lines of command that were slow, loosed information, prevented to create holistic awareness and were prone to small function optimization. Neither hierarchy nor customer driven management was followed but each function acted individually as they seemed best without understanding of causality and when failed they were protected by thick layer of irresponsible administration.

Figure 5: Planned value chain of MATI 2 development and support organization

The value chain pictured in Fig 5 never functioned since there was no maturity for matrix cooperation, lines of communication were long, functional priorities of each sub provider caused friction and holistic understanding of chains operation was missing.

Getting out

When IOC tests failed a third time in a row, it was clear that this program has failed as a whole. Both communications integrator and quality vendor had pulled out in silence and only customer and BMS provider were left in confrontation situation. When analyzed the procurement process it became clear that there was no clear violation of agreement since both sides had misunderstood intentions and failed in communicating requirements.

It was responsible single people that were managing this situation since organizations were busy doing their administration. Inspector of Signals, head of G6, project manager from G10 and project engineer from Material Command together with BMS vendor came up with settlement which they proposed to Ministry of Defence where the final decision was made. 
Settlement included dismissal of original agreement by both sides. It included a new contract to develop BMS solution to a smaller international force and sustain it to the future.

Success in the end

G6 of Army Command took responsibility to manage this new international capability. They flattened development organization in to Integrated Project Team where representatives from G6, G10, Material Command and vendor worked together. It also helped that vendor had recruited two experts from Defence Forces to help in delivering understanding trough entire program. Since Special Operations Regiment had best experience in using BMS from patrol level upwards, they were tasked to test and develop holistic capability. Signals School was included with task to build IP-based mobile communications infrastructure for peace keeping operations for a company sized force. Development plan with parallel paths of advance was created, clear intermediate goals set and effort to communicate these goals to all stake holders was intensified.

As result BMS was fielded to international operations within companies that were operating in Afghanistan and in Lebanon. Both systems were integrated with other nations either at BFT or MIP –levels to create situational awareness over all forces committed within the same area of operation.

Lessons Identified

There rarely is a military capability that one can purchase as-is from vendors. Capabilities are often composed from DOTMLPFII parts and material component is nothing without other components adaptation.

As fighting system of systems becomes more complex and interrelated there is rarely a one vendor that is able to provide even all technical parts. The basic system engineering model is not best practice in developing complex system of systems capabilities.

Organization is often slave of its origins, culture and legacy systems. If one is not careful, future development is only renewing existing capabilities and not seeking asymmetric and strategic advantages over possible opponents. Since partial optimization and egocentricity is a risk for all projects a program or portfolio level should be very careful to overcome these pits. 

There are cases where lack of maintenance or negligence in updating key modules of one system of systems has led to dispersion of the whole capability. Software defined and interconnected systems should be kept up to date or their will easily flip from strength to weakness.

If single arm is concentrated only to improve their inner capability, there is a danger that it would not support multiarms operations. With integrated force there should not be any separate development program nor project but at least coordination with clear milestones at force capability level. NATO and US Forces have utilized ongoing operation in Afghanistan to improve their integrated effects.

System of systems capability is not based on single subsystem functions but subsystems cooperation. Planning, design and testing should include always whole system of systems structure – either live or simulated.

All datatransfer issues in tactical environment should be modelled and simulated to have better understanding of volatile environment and evolving requirements. If tested scenario is following only existing procedures or topology, there is a danger of major blindness.

If no other modelling is utilized then a small world of larger system of systems implementation should be created as reference environment. Around this sandbox one can both test all changes in configuration but also experiment with possible new components.

One should be careful in introducing long term architecture decisions since installed legacy does not follow new good principles, but needs to be integrated. When introducing datamodel practices one should have clear understanding of the magnitude of one’s force and sample data from existing and possible situations. With this understanding one should start vigorous modelling and simulation before advancing to any implementation. Laboratory environment does not full truth and field tests are very expensive way to find out design failures.

Data and information flow in tactical domain is very much dependent on tactics and battle technics used. Adopting models from foreign forces does not give similar capability to your force until you change whole stack of DOTMLPFII components.

If customer is not able to create testing procedures or test environment with use cases, there is no clear understanding of required capability and the way how new subsystems are integrated to existing structure and processes. Testing, even in systems engineering way, is a sequence of tests that should utilize information collected from whole test track record. 

If so called ‘show stopper’ emerges during testing, one should have parallel courses of action to proceed. Otherwise one failure in pure sequential procedure will become a major risk for whole project. One should not neglect failures but encapsulate them in order to proceed with other features and come back next time with remedy.

Modern software defined processes may be developed either tailored to customer defined processes or adapted as-is implemented in turn-key system. If force is not aiming to follow fully for example NATO based art of operations, tactics, order of battle and has similar weapon systems, one should not adapt NATO based processes, symbols or terminology as-is. Adaptation will most probably fail since there is no required maturity of tactical understanding or battle technical skills. Old habits are hard to get rid of at staff processes and combat level leading. It requires multitude of simulation training to get rid of old habits and adapt new ones.
With software defined technical systems also maintenance and sustenance are to be changed from legacy model of ‘box’ or component based repair. Immaterial asset management and software updates become major challenges for logistics.

Document driven development is suitable for small system development and quick delivery projects. ‘Sprints’ should have clear stories and prompt delivery. When complexity and interrelationships increases a more iterative development approach should be implemented with several parallel courses of action. Spiral development with many practical testing phases through laboratory, reference and pilot environments is more risk driven approach that is recommended for CIS system of systems development programs.

Normal military planning with different scenarios, decisive points, commander’s intention and ‘WHAT IF’ sensitivity testing should be implemented also in capability development programs. Clear customer driven approach normally helps to align number of different units along value chain because people has tendency to do meaningful work.

Developing Tactical Communications for Renewed Land Fighting

1. Introduction

This paper describes shortly, how land forces tactical communication systems were developed between 2006 – 2012 in Finland in order to support land forces renewed fighting. The approach is to introduce lessons especially from program and risk management point of view as perceived by author. This is a story of traditional attempts, normal failures and gradually improved risk management, which aligned with DOTMLPFII development enabled major improvement steps in force integration and fighting capabilities. Study is based on writer’s personal observations along life cycle of land forces communications development and maintenance program.

2. A short history of land forces tactical communications before 2006

A Quantum leap from II WW -time communications to first digitized communications

During 1980’s Land Forces communications system was changed in a way that enabled totally new ways to command and control. Before introduction of messaging system voice was main means of communications from company to brigade and beyond as utilized by Gen. Guderian  in Fall Weiss -operation in Poland 1939. Nokia Special Electronics produced Messaging system (Sanomalaite m83), that enabled encrypted short messaging on both radio- (AN/PRC-77) and field telephone (LB-field telephone m70) communications. Messaging system provided new age of both man-to-man (free format) and later man-to-machine (variable format) communications and accelerated surveillance, reconnaissance, indirect fires processes together with anti-aircraft artillery fires processes. It also enabled joint fires and joint fight with Army, Navy and Air Forces land based components. 

Late 1980’s saw first digital field communication system to replace mainly Local Battery field telephone connections within brigade and above. Brigade’s digital field communication system (YVI 1) speeded voice connections and increased their survivability but also created first messaging nodes within forces and flattened traditional hierarchical communications to more process and area of effect driven. This was the first time when communication lines weren’t following line of command anymore in Finnish Land Forces. Both combat and combat support functions within brigade were streamlined with these new means of communication. First computers were used in command posts to enhance staff work. This signals digitalization with other improvements in mobility, air defence and surveillance created new capability that was called Brigade m90, a very agile combined arms force with digitally automated communication system. Whole transformation of a brigade structure was successful because of holistic transformation program that was headed by process owners (Inspectors of Arms) and Chief of Army.

Meagre update with best systems out of military shelves

Land Forces started their next modernization in late 1990’s with Brigade 2005 program. This program introduced new field network system (YVI 2) with further distributed switching topology and increased bandwidth for both voice and message communications. Legacy combat network radios were replaced by digital radios equipped with crypto and ECCM functions (LV 241 –family). Messaging system was updated (m90) and Brigade command posts were equipped with automated Command and Control systems (JOTI –family). Signals updated systems were more survivable in battle space under heavy fire and jamming. Messaging system was integrated with C2-systems, which speeded up combat processes especially in intelligence, artillery, air defence and logistics. But like in earlier modernization focus of improvements were majorly at Brigade staff and combat support level, whereas battalion and lower levels remain almost intact. Later C2-systems requirement for better local data connections was fulfilled with ATM-switches that provided field Ethernet-services within command posts. Systems were up-to-date from military shelves (MOTS), but battle processes and tactics remained mostly traditional although automated information management increased some main support processes together with command and control. Fielding of command and control systems succeeded in artillery, intelligence and air defence, but failed in other command posts mainly because focus was more system development than C2-process transformation. Brigade 2005 program was also divided into three courses of action and drivers were mainly the three parent brigades of Kainuu (Northern terrain), Karelian (Eastern terrain) and Pori (Western terrain). This ended up with three different outcomes of combined arms battle systems with different processes and levels of maturity.  See fig. 1 for Signals evolution from M80 to M05.

Figure 1: Evolution of Land Forces Communications from M80 to M05

3. First attempts to define something that enables advantage

Separate strengths become weaknesses when combined

Land forces communications development within two previous decades provided outcome with three different field communications systems (m80, m90 and m05), that were each best at their category but not interoperable with each other. When utilized together in evolving missions and demanding area of operation, each of their weaknesses were summed up and produced major points of failure. The interoperability level of three different systems was degrading all achieved counter-counter measures; data management advantage was inclined with a mixture of automated and manual processes; and mobility and survivability was taken away with adversary’s advances in signal intelligence, jamming and artillery fires.

Is there anything new available in military markets?

Early 2000 military markets were full of systems that were even better than five years before, but markets projected the late cold war thinking of combat systems and there was no real solutions for data communications, better bandwidth with ECCM capabilities nor were there anything in command and control that really promised changes for infantry combat. U.S. Army had their Force XIX, IDF was digitalizing their brigades, but everybody else were more keen on theatre level capabilities amazed by II Gulf War operations than any tactical level improvements. Titaan in Netherlands 2002 and TOC  in Finland 2001 were showing next generation solutions in C2-structure for mission level. TETRA-system implementation in Kosovo 2003 within Deployable COTS Network concept from Finland was changing peacekeeping operations communications, but there was no real advantage gained in actual combat conditions. Combat radio network vendors were focused on improving their Low Probability of Interception (LPI), Communications Security (COMSEC) and other electronic counter-countermeasures (ECCM) but better bandwidth with packet switching was too advantage.

Can we utilize anything developed in civil industry?

Meanwhile wireless technology had leaped in civilian markets producing different (WLAN, WIMAX, 2G, 3G, Flash-OFDM) waveforms. Many parallel waveforms brought up the need to integrate them in one transceiver thus software defined radio (SDR) concept was created. In Finland Defence Forces started investing in SDR development 2001 onwards. Commercial satellite communications advances provided better services (Mobile phone, narrowband IP-connection) than legacy military communications satellites which suffered lack of investments and performance. Packet switching technology had survived after Telco driven ATM-hype and stabilized both IETF-driven MPLS- and Metro Ethernet –switching markets. Voice circuit switching had been replaced with Voice-over-IP –services with struggle between Telco and IETF standards. Open source programs introduced new ways to develop military specific systems utilizing civilian basic functions. Linux-operation system introduced new possibilities to utilize same platform, but tailored for different purposes. Every military force was experimenting with COTS-technology and some traditional Defence Communications vendors were threatened by civilian solution providers. Only salvation to traditional Defence industry seemed to be interoperability and COMSEC requirements that military society was not able to change in the pace of technology evolution.

What are we actually doing?

As mobile communications, personal digital assistants and advanced information management tools were accelerating the productivity of private sector, military was also after new capabilities. Concepts of Effect Based Operations were learned from Kosovo operation 1998 and tested in Iraq operation 2003 and further in war between Israel and Lebanon 2006. All lessons indicated the need of more agile force, better effect at tactical level and more understanding for strategic corporal. 

Future Soldier programs were drafted as infantry was keen on getting cool looking gadgets from digitalization programs and new cyber competence recruits had adapted from Internet war games. Wildest industry dreams included Head Up Displays (HUD) within helmet and extended reality environment to each soldier. Fortunately some field studies ended these visions, finding again that sight is not best way to communicate with human being in stressful situation but hearing and feeling.

To make sense of all ongoing things and future requirements in Finland, studies of future battle was conducted first at literature level, then capturing lessons from military history, further defining alternative concepts of combat, and finally having war games assisted with operational analysis tools. While this was ongoing, something was required to do in able to prepare Signals for the next leap of communications and information systems in battlefield.

4. Three parallel courses of action

Since end state for land forces fighting concept was still under development, no definite requirements for Signals capabilities was given. Although it was clear that communications together with data management technology would be the major enabler for future forces integration. Thus it was imperative for Signals to proceed with tactical communications, three parallel courses of action was adapted: (1) Commercial technology utilization, (2) Open Source based tailored system approach and (3) military-of-the-shelf -solution. These parallel projects were implemented simultaneously in quest of capturing wider understanding and different initiatives. COTS application presented widest ground for crowd sourced development since Cisco routers and switches were widely used in fixed networks of Finnish Defence Forces. Ascom access network system was chosen for open source course, because it was widely used in Navy and Joint access networks and provided good bases for development with agility of a small Finnish vendor. Material Command was given the task to seek any applicable military solutions from MOTS –markets and Signal School heads up to survey other forces in international exercises. 

Figure 2: Three parallel courses of action to seek possibilities for tactical communications improvement

Commercial of the Shelf (COTS) IP solution with Cisco routers

As Cisco routers and switches were widely in use around Defence Forces and first field trials were done as early as mid-1990’s, they were natural source for troop initiatives in tactical land IP-network experimentation. Tuning IP-packets to fit into narrow 16-32 kbps circuits optimized for voice connection was challenging. Especially when quality of connection was mostly below 10 -6 BER. Routing was another problem. Connecting together larger networks created too heavy routing traffic for narrow bandwidth. Familiar OSPF was either too slow or too heavy for tactical routing. Management of Cisco routers was either Cisco Works type or relied on SNMP-protocol, both quite unsuitable for narrow band connections and conscript training. Basic pessimists were arguing that taking COTS-devices to field conditions is not a solution and they do not last long dust, moisture, cold and heat. In real world surprisingly few COTS -devices were damaged by environment causes. It appeared that physical interfaces wore out because of repeating cable connecting and disconnecting during training. 

The fact, that Cisco IOS was educated in most technical schools and conscripts were familiar with using IP-connections at home, created advantageous conditions for accelerated conscript training and provided faster adaptation than military specific system interface. New technology required more from instructors than from their disciples and it took some time for instructors to change first their attitude and then their competence.

Tailored solution based on the family of open source access systems

Since Navy and Joint access networks had implemented tailored open source solution for their usage, this option was decided to be starting point of exploiting new possibilities. Access router did already have WLAN, RJ-45 and fiber optic interfaces attached to Linux platform with open source routing, encryption and VOIP packages. Routing was not applicable as is, system management was web based, VOIP -service was for access point use only and cabinet was not ruggedized enough, but structure promised good options for further development with reasonable price. Routing optimization was on way to more field friendly protocol, adaptors with legacy field systems were under design, open source encryption package enabled tailored configuration and even with VOIP –services vendor had a plan to build more distributed design. Implementing IP –packet transfer in narrowband (1024 kbps) and disrupted (BER < 10 -6) channel remained only real technical challenge. Thus testing and experimenting was focused on finding solutions for this.

In the midst of development process owners of this small agile company sold their shares to Ascom and international enterprise with different working culture was not able to keep original development team aboard. This resulted a chain of changes in development team, loss of communication with customer and in the end loss of the trust of customer. Unfortunately people at customer’s side changed also. New stake holders did not study original plans but created their own, some points of connection were too busy to pay enough attention on what was going on, project managers changed from iterative development to waterfall development with different priorities and strategic level forget to give direction and communicate totally. 

All this resulted a situation, where vendor was not able to meet environment tests and had difficulties to provide tactical EUROCOM -interface. Secondary requirements for end state point of view, but become acute and with high priority in procurement process. Short term failures ended up with contract dispute and withdrawal of both sides. 

Military of the Shelf, (MOTS) solution

Defence communications providers had either products that were based on digital ISDN –exchanges or they were promising to deliver All-IP functions in their next versions. ISDN and voice circuit was there because NATO’s inability to follow development from circuit switching to packet switching technology. NATO legacy was too extensive to make swift changes. New members like Poland adopted different bath and designed field systems with domestic providers that had only outer interface with NATO ISDN. Thales had SOTAS -family of field devices, but their features were immature at that time. Kongsberg had new IP-switch only as a prototype. General Dynamics had something under development but no products. There was plethora of small and agile companies that had ideas but lacked founding. Bigger Telco vendors like Cisco, LME or Alcatel did have ruggedized products, but their features did not differ majorly from their COTS –products and they had closed programs with big price tags for tailored development.

When asked information on estimated prices and maintenance costs, traditional defence vendors gave price tag that were either defined for smaller forces or too long life cycles. They overprized themselves in competitive market where smaller open source companies or COTS products were infiltrating.

5. After successes, failures and sense making, a road map appears

Crowd sourcing may bring up solutions and they are quickly adapted whilst promoted by peers

While misfortune in two courses of action, there was welcomed initiative coming within Signal troops. As team of officers and engineers were experimenting with Cisco-routers and YVI 2 –channels they found out that several 16/32 kbps channels was possible to trunk together and provide more bandwidth to data connection. Four trunked channels provided 128 kbps gross bandwidth for IP –transfer and still enough channels was left for voice circuits. Team was further encouraged to design whole IP-network for brigade and come up with prototype construction. This happened in one annual C4IS -integration and demonstration exercises, where team showed the design and configuration to other units around nation. This accelerated Tactical IP -transformation (TACTIP) adaptation in other units since it was advised by peers, recognized in shared occasion and implementation did not require huge effort.  

MOTS and COTS procurement differ and need special competence

Buying COTS devices via military equipment procurement process appeared to be difficult since Material Command did not have competence in COTS maintenance procedures with annual updates and clauses in warranty conditions. They were also having difficulties of not following waterfall procurement approach, when they were asked not to arrange competition between products but possible vendors of field proven product. Because procurement decision was not based on lowest item prize but total cost of life cycle of whole fleet of capability, which was mainly service, they were uncertain with comparison criteria. This unfamiliarity of COTS-procurement delayed the delivery of routers to units already in waiting in a degree, that a bypass was needed to get initial devices fielded. Procurement bypass was provided by Defence Forces C4 Centre with better competence of similar COTS systems utilization.

Complex system of systems, as field communication system is, needs reference environment to manage changes, configuration and problems together with improved communication between people

As brigade base network was updated with COTS routers mainly installed by units themselves, the Material Command expressed their concern on configuration management and safety of operation. This created a window for opportunity to create a reference environment in order to manage coming tactical communications systems transformation. Material Command, Signal School, Maintenance Facility and main vendors were asked to join in this quest of managing changes and being able to solve together 2-3 level problems of complex communication system. Reference environment also provided tangible “small world” for all engineers and officers to come together with their requirements, problems and possible solutions, thus the time from problem detection to implementable solution shortened drastically. 

Within 5 years period any development program faces changes, new possibilities and problems

As other courses of action slowly withered or were doomed with problems, COTS line was successful. Technology was not the best for task, but required competence was easily achieved by conscripts and devices were expendable because of low unit price.

Signals tactical and technical training was started ahead of supported units. Instructors and leaders training was scheduled ahead of troop training. Since time table and requirements changed, two parallel baths was defined for Signals as presented in following figure 3: 

1. Model 12 that was constructed from updated legacy communication systems and provided new services by COTS –devices. 
2. Model 18 that would follow m12 starting from 2018 with totally new technology, but matured tactics and processes matured while training and exercising with m12. 

A spiral development approach was adopted for m18 with test, reference and pilot environments and equivalent feedback loops to achieve required DOTMLPFII -maturity before fielding. 

New technical possibilities appeared while building m12 capabilities. After various experiments with COTS-devices and their vendors, a new domestic producer appeared. A Finnish company with mainstream in mobile communications and special systems was able to pilot Software Defined Radio platform that included major features of the failed Ascom access node. 

Figure 3: Two lines of development for new tactical communications capabilities of renewed fighting

This was a result of Nokia driven development started early 2000 within one of the best technology hubs of Finland, where University research, Nokia vision and resources, SME agility and Government funding was integrated. Lessons in Software Radio development were adapted from civilian mainstream and shared with international military SDR development forum. Lessons from Ascom node was shared with company and their military counterparts for not to repeat past failures. A small steps approach was adopted with renewed procurement processes in Material Command to mitigate risks that always follow introducing of new technology.

Signal School’s development and education co-operation with Aalto University was able to produce a prototype for new field messaging software. Field message solution was simpler to use but much more efficient than existing Nokia based messaging system. It included tailored encryption and promised to be able to maintain the main capability of combined and joint collaboration between men, machines and organizations. All these new possibilities were able to be included into m18 plans, because m12 was taking timetable pressures out and providing sufficient services for tactics and processes to mature. 

Signals needs requirements and drivers from other arms to be able to multiply their combined effect

As m12 services were trained, land forces renewed fighting concept matured in war games and first field tests started to give better understanding of new requirements for Signals. Operational level requested better understanding of situation and foresight in possible scenarios. Tactical level required swarming tactics with platoons and patrols to be more agile when facing adversary. Combat technical level required more efficient processes for combined arm effects. Combat support services required on-time control of support network with client driven processes as depicted in following figure 4. 

Figure 4: An example of four levels that were matured within renewing Land Forces fighting

6. Intermediate solution Model 2012

System of systems calls for integration and optimization both horizontally and vertically

As TACIP solution with COTS –routers provided new services, other parts of m12 land communication system of systems was defined and new concept was designed through extensive integration testing and experimenting with different solutions. After trials a compromise configuration was found for both YVI and router structure, which provided near null-configuration even when connections and topology were changed. 

To get other parts of technical capability up to date with TACIP services, last midlife update for Nokia message system was executed. This improved geographical information interoperability with some encryption features and extended systems lifecycle to meet m12 requirements. IP connectivity provided more bandwidth to messaging with better routing to survive changes and kinetic effects in area of operation. It also solved message network routing problems with more effective IP-routing.

Since legacy Combat Radio Network was not able to handle IP-packages, messaging remained as an important connectivity and encryption layer for m12 communications. All Army command, control and information systems were able to communicate via messaging system so troop leader were able to order support from all arms within the brigade. Old messaging terminals were substituted with field computers that included messaging application together with Battle Management System applications.

Because field radios in Combat Radio Network (CRN) –system were old, their producer did not provide any maintenance services or spare parts for them. It required a special arrangement to extend life cycle of whole fleet of radios to meet m12 requirements. Distributed maintenance and storage was discontinued and centralized maintenance unit was founded with responsibility of whole radio fleet and its lifecycle. Some radio units were assigned for spare parts (cannibalization) and life cycle readiness requirements were set to drive sustenance for remaining life of devices. 

Capability is not only material items but all DOTMLPFII components functioning together 

Signals new capability included changes also in other parts of DOTMLPFII structure as explained in figure 5, thus Signal School arranged several Signals tactics and doctrine workshops to create and deliver required understanding. This was aligned parallel with land forces fighting doctrine development in many computer assisted war games and live exercises. With this design process other arms, especially infantry, artillery and sappers, did set their requirements to Signals support and in the end state combined effort created more capability than merely their sum would be able to project.

Organization was changed to support better online network operations and maintenance. Most challenging was to transform deep functional organization with sub optimized procedures to service provider’s value chain that is driven by client’s needs. Also distributed way to employ troops but with coordinated way to effect to adversary, was requiring a lot from leaders, communications and logistics.

Training was scheduled within Signal School, Reserve Officers School and other Signals units before user training commenced.  This provided readiness of service that Signals needed, when troop leaders and platoons training began. Material and software updates were provided always through reference environment, where it was tested together with all stake holders of Signals capability, harnessed, integrated and delivered to operational system of systems with balanced performance. 

Both platoon leader’s, forward observer’s and signal officer’s leadership skills needed to be transformed. First two leaders were trained to act even more as a team and utilize combined arms effect in fighting. Signals officers were trained to be more supportive towards fighting and same time more capable to manage distributed and independent patrols. 

Maintenance personnel was appointed to take care sustenance of programmable electronics. Long leap was taken, when repair shops specialized to analogue technology, warehouses with optimized off-line device management and ICT-support units with device focused procedures were transformed to support on-line warehousing with configuration management and disposable devices. 

New facilities were built to support both training and maintenance of new systems. Intensive training required new base stations and connection points within garrisons and exercise areas. On-line warehousing, in which all communication units were stored on line with power switched on, required new cabling on shelves.

New information sources like weather forecasts for artillery, digitalized RAOP –data for air defence, Blue Force Tracking data from other components and Joint level operational picture data was directed to support units situational awareness. Additional information exchange gateways was build and information flows was directed to support all fighters. Focus of information management shifted from command posts to units and domain boundaries were pierced by flows of new information. This really transformed both information management and combined fighting for new possibilities. Legacy processes were questioned by new possibilities appearing with new information.

Figure 5: An example of DOTMLPFII capability components and coordination of their development

Interoperability within technical system both horizontal and vertical dimension was guaranteed both with reference environment and with annual integration and interfacing exercises. Interoperability through whole DOTMLPFII -structure was assured in pilot environment, where all bigger changes were tested, practiced and mapped before fielding into operation. Eventually change management was following three different flows of weekly, quarterly and bi-annual delivery. Weekly updates included smaller patches, configuration corrections and information assurance remedies. Quarterly changes included larger updates of operation systems and applications. Bi-annual changes introduced new features and services, which were required by units in field.

Doctrine includes management that starts with capability life cycle planning, which in one hand takes care of smooth transformation, but in other hand strives for strategic advantage over adversary’s capabilities in probable area of operation. It goes through program and portfolio management and is not afraid to give freedom to Corps initiatives when opportunities appear. It creates collaboration between various stake holders to keep everyone within same understanding and level of communication. It ends up with stabilized structure and processes to deliver quality services and continuously improve their effectivity and utilization.

7. Stabilizing the maintenance, development and risk management of communication system of systems 

Between developed technology and service requirements from units, Signals needs to follow continuous development principle

Signals transformation was not only introducing COTS –technology to gain quick wins, restructuring organization and implementing new procedures, but also creating long term procedures and culture for continuous improvement and change management.  Doctrine, organization and tactics were studied and developed in Signals annual tactical seminar, where previous years performance metrics was analysed and new possibilities were introduced. Education, training and learning were improved via Signals annual training seminar, where metrics of previous year was studied and new measures for education was introduced. As continuous system change was either pushed by provider’s technical updates or pulled by client’s functional requirements, annual technical interoperability exercise brought Signal troops together to implement new devices and services, test their interoperability, fix their service processes and learn from each other.

Bi-annual field exercises for conscript troops

Since conscript troops are produced bi-annually in Finland, there is a series of unit exercises at the end of each training period. These exercises train and test combined arms co-operation within battalion task force with live fire. This provides ultimate peace time framework for Signals troops quality and effectiveness measurement. Each signal patrol, each level of technical system and whole task force C4I –system is measured against value they are providing to other combined arms in fire effect, agility in movement and survivability in hard conditions. These measures together with commander’s judgment gives basis for estimation capability sustenance of signal units in reserve. Measures give also tangible drivers for Signals to improve their services without continuous operations in warlike environment. This is captured as goals for following year’s plans and orders for each training and service providing unit in Signals. Without these national defence exercises, Signals may be tempted to follow only lessons identified in peacekeeping operations and that would not prepare forces for next war. 

Life-cycle management of Signals C4I –system of systems

New, legacy, extended life-cycle and COTS devices are integrated to a C4I -system of systems. This technical complexity together with Signals personnel and procedures are enabling combined arms tactics, functions and procedures. This intertwined structure creates a new kind of capability life cycle management challenge, which is introduced in figure 6. This pace of change is confronted with lessons identified from current operations in Iraq and Afghanistan, where adversary is able to learn and change their fighting technics within 24 hours by utilizing differently COTS –technology, facilities and terrain familiar to them.

Figure 6: Some examples of Signals system of systems change cycles 

System of systems changes should be done by value chain in continuous flow mode driven by performance that is a balanced between client needs and system vulnerability. No C4I -system of systems is isolated any more from surrounding structure, information flows and many processes passes over organizational boundaries. Every chain is as strong as the weakest link. Technology, competence and procedures must be updated aligned to keep the chain equal strong. There are some general update times for C4I –system of systems presented in previous picture to give example of required pace of change in networked force.

Signals needs value driven procedures that provides a service flow to supported combined arms forces

Signals assets creates intertwined system of technical systems with both horizontal topology and vertical layers. This is integrated with people and processes to create holistic C4I -service provider system of systems, which by itself is of no value. It is only one part of value chain of combined arms forces and has many interfaces both with fighting components and supporting components. Signals is the glue that keeps distributed combined arms together as a force and multiplies their effort by providing tools for improved information utilization.

This complex, intertwined and continuously changing system of systems requires the  life-cycle management of programmable and trainable capabilities as depicted in figure 7. A continuous flow of services is being provided to clients at same time as both continuous and disruptive development occurs. It is like driving a car on a highway while it is being serviced and gradually changed part by part. Service performance is optimized to meet combined arms tactical needs.  Units’ requirements of improvement are fulfilled with fast solution finding by stake holders working together around reference environment. If needed, defined solutions are further tested in pilot environment, before launching them to operation. Same iterative cycle is followed with each update and patch that is provided by subsystem vendors. 

Figure 7: An example of signals capabilities life cycle management

Both legacy and new services are being planned as capabilities and not just new systems that replace older systems. This create value driven logic for new investments, which are first modelled and simulated in virtual world in order to make sense of all possible changes required in existing system of systems. Technical solutions for modelled services may be experimented in both experimental and reference environment, where both existing providers and new vendors share awareness of future needs and possibilities. 

Procurement is then given a task for iterative development with bi-annual delivery goals that are coordinated with cooperation in reference environment. After technical integration in system of systems reference environment, change items are further tested in pilot environment to integrate them through all DOTMLPFII dimensions. Eventually change items are ready to be delivered into operation in one of the update windows or suitable rotation of troops. Every change is prepared and followed with guides, training and feedback gathering.

8. A road to next generation solution

Utilizing the lessons identified in developing Model 12, it was less risky to plan a holistic DOTMLPFII capability road map for next generation Model 18 development. Road map was constructed from sequential loops called spirals, where advance is achieved by small iteration that are being tested and fielded while learning all the way. The best feedback was provided from m12 training and exercises, where other arms and services were improving and learning renewed fighting. As new requirements was captured from process development, several possibilities were experimented in technology line of operation. Suitable technical increments were forwarded to integration testing and further to pilot testing. This provided agile method to advance at the pace of combat development and not be driven too much by fanciest technology.

Spiral development with continuous cycles through laboratory, reference and pilot environment 

Laboratory and reference environments were created side by side to provide the best possible understanding and collaboration framework to all vendors and stakeholders. Pilot environment was appointed to a whole brigade, where all arms were combined for testing and training of renewed tactics. Reference environment supported pilot by delivery testing, problem management and spare parts. If technical problem was faced in the pilot environment, the root cause was analysed and solution found in reference environment. Spiral development is described in figure 8.

Figure 8: An example of spiral development in software defined C4ISR system of systems

Since process and application development was based on semantic knowledge model and communications systems were mainly software defined, it was possible to utilize independent spiral cycles for each layer of applications and communications. Main version (vX) spiral was annual, but sub spirals (vX.y) were spinning quarterly. Application layer and information model was developed with quarterly scrum sprints and iterations were introduced over communications structure first time in laboratory environment. After first spiral feedback both application and communications were adjusted to second laboratory test cycle. After second successful tests, system was duplicated to reference and pilot environments. Pilot brigade started conscript training, whereas engineers continued to finalize configurations in reference environment. Simultaneously second main spiral started with process iteration and knowledge model workshops in order to create new capability iterations for future sub spirals.

Value driven perfection by client and not by providers or contracts

The quick pace and small iteration steps made it possible to adjust any feature separately in application and communications layers according to tactical and combat technical maturity or phase of training. Development listened very carefully comments coming from pilot brigade. Because pilot brigade had best understanding of holistic DOTMLPFII development situation, they were delegated the decision of proceeding pace within the year. The entire development chain was adjusted to bi-annual decision points including contracts with vendors. This ensured that technical development was supporting other capability components in combined balance and whole value adding chain was following user’s feedback to achieve best usability. Laboratory environment was utilized as technical development buffer, where more advanced or accelerated features were tested but then downgraded to enter to reference environment. Twice a year pilot and reference environment was updated with new capabilities whereas patching and configuration changes were made weekly or quarterly.

Program office was controlling development at annual level agreeing on annual goals with all stakeholders and issuing resources to achieve them. Risk management was additionally managed with several parallel options:

• Annually major problems at technical development were mitigated either by using latest functional system version in training or substituting missing feature with nearest COTS-capability.
• Where ever technical development was proceeding faster, it was allowed until laboratory testing, but downgrading to balance other features was insisted from reference environment onwards.
• Each annually agreed delivery was required within that year and within agreed price. Within year variation was allowed, if it was kept within training schedule of the pilot brigade.

This produced one time a situation where pilot troops were using four versions older BMS over two versions older messaging system that was using one version old routing program but one channel was substituted with nearest equivalent COTS -communications system. Complexity of this kind was possible because of strict integration testing with heavily adhered testing routines and good communication between developers and testers.

9. Summary

Developers have same weaknesses as any humans. They tend to forget information that does not support the adopted line of their thinking. They tend to narrow their path as time goes and problems occur. They tend to be the only ones that understand how things should be done and they tend to become blind to any evidence that contradicts their profound believes. If Signals is given freedom to develop their capability independently, they most probably will come out with best technology but not that good services the other arms are needing. It is imperative to deliver intent of whole program as understandable as possible through all stake holders to align all efforts towards same capability goal.

Large enterprises and alliances tend to stick with systems, standards and procedures that are good for interoperability but may kill any strategic advantage in long run. New solutions are often found outside the legacy stake holders and utilized only by those that have vision and will at right moment. This calls transformational leadership whereas more transactional management tends to prefer familiar solutions.

If development is divided to narrow functions with independent decision making, one often end up with sub-optimized solutions that might nullify all good features when integrated together. Portfolio management requires tangible values that every project is following with agility because real life seldom follows theoretical plans.

Portfolio management should consider parallel courses of action, when either end state or path is uncertain. Sometimes best initiatives may come also from field units and not necessary from procurement engineers or defence vendors. In information and communications technology currently defence initiatives are rare, whereas mainstream of development is in commercial services. On the other hand open source components are providing fruitful possibilities to both defence vendors but also to their new challengers. Military capability developer may collect some good initiatives if they explain their problem clearly in Request For Information and publish it wider than only to legacy defence industry. 

Procurement procedures needs to be changed if military, government and commercial technology is mixed. Waterfall development method proved to be unsuitable for any system of systems development but stands on it’s ground in small subsystem development.  Spiral development has proven to be best method for managing iterative changes in complex C4I -system of systems. Any project will face probable failure if communication between people and organizations is not functioning. Even organization cultural differences may produce difficulties between points of contact.

One has to follow and understand technology and markets, since it is not always the best technical solution that champions in markets. It is sometimes the brand, package or channel that decides who wins in current markets. C4I –services life in markets is shorter than any time before. It is seldom that modern IC-technology can endure 20 – 30 years in service as sometimes expected in military.

With C4I -system of systems the interrelationship with all other systems makes it almost impossible to change anything independently. Even standards are short lived, when default agreements rule. There is always next version in coming, which is always better than any previous product or service. Only system in training and full operation is capability.

Technology itself is not force multiplier but when machines, men and procedures are trained as integrated system and supported with better information, then force effect may be multiplied. One should consider always other parts of DOTMLPFII –capability structure when pursuing to develop integrated military force.

Networked technology requires maintenance and updates delivered at same pace as other nodes in value chain. If one part of that technology chain is outdated or noncompliant, that node becomes the weakest link of the whole value chain. This requirement extends over organization borders to all networked stake holders. Unified and agreed security and maintenance policy should be implemented though network with transparent audit track.

It is mistake to think that within 5 years long development program there will not be any changes, problems or new solutions. As in any military planning, one should keep close eye on assumptions of the plan that is under execution. In development programs stubbornness is not necessary the way to success. But it is sadly the only way, if there is no risk or agile program management aboard.

One might utilize the newest technology as a first adaptor, but implementation needs more time, development steps should be careful and one should have alternative solutions if one part of complex structure fails. After all there is a possibility to gain strategic advantage with early adaption of latest technology. In the end of the day it might not be the newest technology implemented, but development and maintenance process that has been adopted with technology that provides unrepeatable asset at strategic level.

If one does not have enough investments to replace all sub systems within short time and possibility to train all forces at once, one should be prepared to extend the life cycle of legacy systems as a part of new system of systems capability.

If one focuses only developing capability with investments, one might not achieve advantages of continuous development, which may be even better. Competent and motivated personnel can develop capabilities faster through small changes than force is able to adapt with waterfall development. This is case at least in conscript and reserve force since there are so many different professionals coming together to defend their country. With continuous development one must identify the value, measure it and publish results through to the whole force projection chain to enable learning and improving.

It might need to establish on-line warehouses to maintain programmable electronics at up-to-date level and configuration ready for operation on demand. This calls for new competence, skills and procedures from existing support, repair, storage and maintenance personnel.

C4I system of systems development and maintenance is too complex process to have long lines of communication and deep hierarchical command structure. Flatter the organization and shorter the lines of collaboration, the better understanding between stake holders and lesser risks. One cannot buy system of systems of the shelf, thus integrated project team is imperative.

Next generation technology promises major advantages, but requires more maturity from all stake holders of development and maintenance network. As always technology can provide short strategic advantage, but in the end it is more of organizations capability to continuously improve their capability, than long, risky technology leaps that may crash land. It is coming rare that one man can understand or one vendor can provide all that integrated military force is requiring for next generation capabilities.