Εθνικό Σύστημα Διαχείρισης Μάχης: Μήπως πρέπει να μας απασχολήσει;

Του Μίλτου Αντωνιάδη

Θα ξεκινήσω δηλώνοντας πως ο σκοπός αυτού του άρθρου δεν είναι να πριμοδοτήσει τη μια ή την άλλη υποψηφιότητα για τα νέα καράβια του ΠΝ. Ορμώμενος φυσικά από τις κεφαλαιώδους σημασίας εξοπλιστικές εξελίξεις για τη χώρα, αλλά και την καταιγιστική ειδησεογραφία, θέλω να θίξω ένα θέμα:τα Συστήματα Διαχείρισης Μάχης (CMS) των πολεμικών πλοίων,  που φαίνεται συχνά να περνάει στα «ψιλά», σε σχέση με πιο δημοφιλή θέματα όπως οι πύραυλοι, τα σόναρ, τα πυροβόλα και τα CIWS. Οι επιλογές των πολεμικών πλοίων γίνονται φυσικά με γνώμονα πάρα πολλές παραμέτρους, το CMS δεν είναι παρά μια μόνο από αυτές. Πόσο σημαντική είναι τελικά;

Ο ρόλος του CMS σε ένα σύγχρονο πολεμικό πλοίο

Ας ξεκινήσουμε από τα βασικά. Οι περισσότεροι, κι’ ας μην έχουμε πατήσει το πόδι μας στο Κέντρο Επιχειρήσεων μιας φρεγάτας, λίγο-πολύ καταλαβαίνουμε σε κάποιο βαθμό τί κάνει ένα CMS. Σύμφωνα με έναν απλό ορισμό ⁽¹⁾, το CMS συλλέγει και ενοποιεί την πληροφορία από αισθητήρες του πλοίου και εξωτερικούς αισθητήρες, την παρουσιάζει στο πλήρωμα και του επιτρέπει να δράσει. Ακόμα και από αυτόν τον γενικό ορισμό, αντιλαμβάνεται κανείς ότι ο ρόλος του CMS εξελίσσεται σε ολοένα σημαντικότερο συστατικό όσο η τεχνολογία εξελίσσεται. Διότι:

• Τα ίδια τα πλοία διαθέτουν πολύ περισσότερους αισθητήρες σήμερα από ότι παλαιότερα.
• Ο όρος «εξωτερικοί αισθητήρες» αναφέρεται φυσικά σε μέσα που δικτυώνονται πλέον, όπως τα ελικόπτερα, τα UAVs, UUVs, ΑΦΝΣ, ΑΣΕΠΕ, μαχητικά, άλλα πλοία.
• Οι απειλές εξελίσσονται επίσης, συνεπώς ο χρόνος που απομένει στο πλήρωμα για να αντιληφθεί την τακτική κατάσταση και να αναλάβει δράση περιορίζεται σημαντικά.

Με άλλα λόγια, αν το CMS ήταν ήδη σημαντικό από τη δεκαετία του ’80, στη δεκαετία του 2020 είναι ακόμα κρισιμότερο για τη μαχητική ικανότητα του πλοίου. Ενώ στο μέλλον, θα μπορούσε κανείς να πει πως θα είναι ο συντριπτικός παράγων καθορισμού της ναυτικής ισχύος.

Μπορεί να ακούγεται υπερβολικό, αφού τα πυροβόλα και οι πύραυλοι θα καταστρέψουν τον εχθρό στο τέλος και όχι το CMS. Άποψη του γράφοντος είναι πως το πλήρωμα θα καταστρέψει τον εχθρό, ανεξάρτητα από τα μέσα που θα χρησιμοποιήσει. Αν τα ραντάρ, τα σόναρ και τα UAVs είναι τα μάτια και τα αυτιά του πλοίου, οι πύραυλοι, τα πυροβόλα και οι τορπίλες είναι οι γροθιές του, το CMS είναι ο εγκέφαλος και το νευρικό σύστημά του.

Ο μεν εγκέφαλος περιλαμβάνει φυσικά και το πλήρωμα που θα πάρει τις τελικές αποφάσεις (τουλάχιστον για όσο καιρό ακόμα δεν υποκαθίσταται ο άνθρωπος από την τεχνητή νοημοσύνη). Όμως τα CMS έχουν αφαιρέσει ήδη πολύ από τον φόρτο του πληρώματος διαθέτοντας προγραμματισμό σεναρίων και προτείνοντας αναλόγως τη βέλτιστη αντίδραση (ποια όπλα, πότε, από ποια κελιά, κ.ο.κ.). Το δε νευρικό σύστημα είναι αυτό που θα καθορίσει:

(1) σε πόσα δευτερόλεπτα θα έχει φτάσει η πληροφορία από τους αισθητήρες σε κάποια κονσόλα, όπου θα παρουσιάζεται αναλυμένη, συνδυασμένη με άλλες πληροφορίες κ.λπ.,

(2) σε πόσα δευτερόλεπτα θα πάρει μια απόφαση το πλήρωμα βάσει των προτάσεων του CMS και της μεγαλύτερης εικόνας που παρουσιάζει (Situational Awareness),

(3) σε πόσα δευτερόλεπτα θα φτάσει η εντολή του πληρώματος από την κονσόλα σε κάποιον τοπικό ελεγκτή του CMS δίπλα στο όπλο ώστε να πυροδοτηθεί και

(4) πόσο γρήγορα θα επαναληφθεί ο παραπάνω κύκλος, ανάλογα με την εξέλιξη της απειλής, την επιτυχία την πρώτης βολής κ.ο.κ.

Το πρόσφατο παράδειγμα της βύθισης του ρωσικού καταδρομικού Moskva άλλωστε, καταδεικνύει το γεγονός πως οι πανίσχυρες γροθιές του (οι αντιαεροπορικοί πύραυλοι S-300) αλλά και η εξαιρετική όραση (τα ραντάρ του), μικρή αξία έχουν αν το νευρικό σου σύστημα αδυνατεί να αντιδράσει με την απαραίτητη ταχύτητα στα ερεθίσματα.

Και αν αυτά συμβαίνουν το 2022, το 2042 τί θα συμβαίνει;

Φυσικά είναι αδύνατον να κάνει κάποιος ακριβείς προβλέψεις στο χώρο της τεχνολογίας σε βάθος 20ετίας. Αυτό από μόνο του όμως αποτελεί μια πρόβλεψη. Με άλλα λόγια, είναι τόσες οι εξελίξεις σε διάφορους σχετιζόμενους τομείς, όπως τα μη επανδρωμένα οχήματα, στους αισθητήρες, στα όπλα (χημικής, κινητικής, ηλεκτρικής ενέργειας), στα πυρομαχικά (πυροβόλων ή άφεσης από αέρος) και στις απειλές πάσης φύσεως (ηλεκτρονικού και κυβερνο-πολέμου), που σίγουρα στο κέντρο όλων αυτών των εξελίξεων – στο μάτι του κυκλώνα θα λέγαμε – βρίσκεται το CMS. Το οποίο οφείλει να είναι ενημερωμένο για νέου τύπου απειλές και να μπορεί να ενσωματώνει νέου τύπου όπλα. Σε ένα κάπως χονδροειδές παράδειγμα, ας φανταστούμε στον προσωπικό υπολογιστή μας ένα πρόγραμμα antivirus που δεν έχει ενημερωθεί εδώ και δύο χρόνια. Είναι σαν να μην έχουμε καμία προστασία. Κάπως έτσι φαντάζεται ο γράφων το μέλλον των CMS και την ανάγκη τους για συνεχή ενημέρωση σε σχέση με απειλές συμβατικού πολέμου, ηλεκτρονικού, αλλά και κυβερνοπολέμου.

Διασυνδεδεμένες επιχειρήσεις

Αυτό το κεφάλαιο δεν αφορά στο μακρινό 2042 αλλά είναι ήδη εδώ. Ανεξάρτητα από τις ικανότητες ολοκλήρωσης του CMS με τα «περιφερειακά» του ίδιου του πλοίου, το CMS πλέον θα πρέπει να μπορεί να υποδεχτεί και να διαχειριστεί την πληροφορία από CMS άλλων πλοίων, ιδανικά και αεροσκαφών, επίγειων ραντάρ κ.ο.κ. Το παρόν άρθρο δεν θα επεκταθεί στο τακτικό κομμάτι αυτής της συζήτησης – στο γιατί δηλαδή είναι εξαιρετικά σημαντικό αυτό το στοιχείο στο Αιγαίο για το ΠΝ, για τις ένοπλες δυνάμεις συνολικά. Αυτό έχει αναλυθεί διεξοδικά από τις σελίδες της “ΠΤΗΣΗΣ”. Εδώ θα επικεντρωθούμε στο πώς είναι δυνατόν να επιτευχθεί κάτι τέτοιο και τί σημαίνει για τα CMS των μονάδων του στόλου.

Naval Group SETIS: To Combat Management System των φρεγατών FDI HN που θα “κυριαρχήσει” στο ΠΝ τις επόμενες δεκαετίες

Περίπτωση Α: Ίδιο CMS σε όλες τις κύριες μονάδες

Το ιδανικό σενάριο. Εφόσον οι μονάδες επιφανείας θα λειτουργούν με την ίδια “γλώσσα”, το μόνο που απαιτείται είναι μια ασφαλής τηλεπικοινωνιακή ζεύξη (τουλάχιστον Link-16 καθώς το Link-11 δεν έχει αντοχή στις ηλεκτρονικές παρεμβολές), ώστε τα πλοία να ανταλλάσσουν εικόνα μάχης σε πραγματικό χρόνο. Τα δεδομένα που θα καταφθάσουν μέσω της ζεύξης στο πλοίο δεν θα χρειάζονται καμία «μετάφραση». Όπως καταφθάνουν θα διοχετεύονται στο λογισμικό του CMS, το οποίο άλλωστε θα είναι ίδιο με το λογισμικό στην πηγή: Ο τρόπος παρακολούθησης των δεδομένων, οι χρόνοι και οι μέθοδοι ενημέρωσης των πινάκων και ένα σωρό άλλα σημαντικά στοιχεία που αφορούν στην αρχιτεκτονική του λογισμικού – δηλαδή στον τρόπο που σχεδιάστηκε εξ’ αρχής – δεν θα παρουσιάσουν δυσεπίλυτα προβλήματα.

Περίπτωση Β: Δύο διαφορετικά «ολοκληρωμένα» CMS

Όχι ιδανικό, πάντως θεωρητικά εφικτό. Πολλές φορές γράφονται και διαφημίζονται από τους προμηθευτές, δυνατότητες των συστημάτων τους για ολοκλήρωση με τρίτα συστήματα. Τι σημαίνει αυτό, σπάνια είναι ξεκάθαρο. Ακόμα και για ολοκληρωμένα έργα υπάρχει ασάφεια ως προς το βάθος της ολοκλήρωσης αφού ποτέ μια τέτοια δεν είναι ίδια. Για λόγους αμεροληψίας, στο παράδειγμα δεν θα χρησιμοποιήσω ονόματα υπαρκτών συστημάτων, αλλά τα γενικά CMS Alpha και CMS Bravo.

Έτσι ο εργολήπτης της ολοκλήρωσης των συστημάτων Alpha και Bravo (μπορεί να είναι ένας από τους δύο κατασκευαστές, ή τρίτος integrator) θα πρέπει να συλλέξει τις ακριβείς απαιτήσεις του πελάτη (Τι είδους ολοκλήρωση θέλει; Σε τι βάθος; Τι διεργασίες θέλει να εξυπηρετήσει; Σε τι χρόνους; κ.λπ.). Στη συνέχεια ο εργολήπτης πρέπει να αναλύσει και να καταλάβει πώς ακριβώς λειτουργεί το σύστημα Alpha, να κάνει το ίδιο για το σύστημα Bravo και μετά να ξεκινήσει τη σχεδίαση μιας λύσης στο χαρτί. Σημειώστε πως μέχρι τώρα δεν έχει γράψει ούτε μια γραμμή κώδικα. Είμαστε ακόμα στη φάση της ανάλυσης, οι ανθρωποώρες βέβαια στο κοστολόγιο «τρέχουν».

Η παρουσίαση της προτεινόμενης λύσης είναι πιθανόν να απέχει από τις αρχικές απαιτήσεις του πελάτη, εάν προκύψουν αγεφύρωτες ασυμβατότητες σε κάποια στοιχεία αρχιτεκτονικής των Alpha και Bravo. Στο τέλος πάντως, ο εργολήπτης θα παρουσιάσει έναν συνοπτικό πίνακα στον οποίο θα περιγράφονται οι δυνατότητες της ολοκλήρωσης που προτείνει για τα δύο συστήματα, σε σχέση με τις λεγόμενες Push & Pull μεθόδους. Με απλά λόγια, Push σημαίνει πως το σύστημα Alpha «σπρώχνει» μια πληροφορία που γεννήθηκε σε αυτό, προς το σύστημα Bravo. Pull σημαίνει πως το σύστημα Alpha «τραβάει» μια πληροφορία που γεννήθηκε στο σύστημα Bravo για να ενημερώσει τη δική του βάση δεδομένων.

Στο παραπάνω υπεραπλουστευμένο παράδειγμα βλέπουμε τον τρόπο με τον οποίο συχνά περιγράφονται οι ολοκληρώσεις μεταξύ διαφορετικών πληροφοριακών συστημάτων. Το CMS Alpha θα μπορεί να «σπρώξει» την πληροφορία για έναν νέο εναέριο στόχο που εντόπισε μέσω του ραντάρ του (create) στο CMS Bravo, όμως δεν θα μπορεί να ενημερώνει (update) το Bravo για τυχόν αλλαγές στα χαρακτηριστικά του στόχου (επειδή για παράδειγμα ο εργολήπτης δυσκολεύεται να συγχρονίσει δύο συστήματα που παρακολουθούν / ενημερώνουν εναέριους στόχους με διαφορετικό τρόπο / συχνότητα). Κάτι τέτοιο μπορεί να γίνει αποδεκτό από τον εντολέα (το Πολεμικό Ναυτικό) ή όχι. Σίγουρα πάντως, για να γεμίσουν τα πολλά κελιά που θα έχει αυτός ο πίνακας με το σύμβολο “✓” θα απαιτηθούν περισσότερα χρήματα και χρόνος. Εφόσον, πάντως, συμφωνηθεί το τελικό μείγμα κόστους/έκτασης της ολοκλήρωσης, τότε μόνον ξεκινά ο μακρύς δρόμος της συγγραφής του κώδικα, των δοκιμών από τον εργολήπτη και των δοκιμών αποδοχής από τον εντολέα.

Συνεργατική εμπλοκή: Όταν οι φρεγάτες FDI θα κάνουν τον «μαέστρο» του στόλου

Περίπτωση Γ: Τρία διαφορετικά CMS

Το χειρότερο σενάριο υλοποίησης. Διότι η περιπλοκότητα του έργου που περιγράφεται παραπάνω δεν αυξάνεται γραμμικά αλλά εκθετικά. Μπορεί, φέρ’ ειπείν, κάποια λύση που δουλεύει για τη γεφύρωση των CMS Alpha και Bravo να «σκαλώνει» στο Charlie, κ.ο.κ. Είναι σχεδόν σίγουρο πως όσο μεγαλώνει το πλήθος των υπό διασύνδεση συστημάτων και η περιπλοκότητα του έργου, τόσο θα μεγαλώσει και η λίστα συμβιβασμών που θα αποδεχτεί τελικά ο εντολέας, αφού, κάποιες δυνατότητες που ήθελε δεν είναι τεχνικά δυνατόν να υλοποιηθούν.

Αγοράζουμε κορβέτες, φρεγάτες ή ένα οικοσύστημα νέων πλοίων; Ο κίνδυνος της «κουρελούς»

Μπαλαντέρ: Ανοικτή και κλειστή αρχιτεκτονική

Αυτό είναι ένα στοιχείο που θα επηρεάσει την επιτυχία του έργου σε όποια από τις τρεις περιπτώσεις και αν αναφερόμαστε (ναι, ακόμα και στην περίπτωση Α). Στην πραγματικότητα δεν υπάρχουν απόλυτα κλειστά συστήματα ούτε απόλυτα ανοικτά, δεν μιλάμε δηλαδή για μια ασπρόμαυρη κατάταξη αλλά για αποχρώσεις του γκρι. Υπάρχουν χαρακτηριστικά που κάνουν ένα σύστημα περισσότερο ανοικτό ή κλειστό.

Ένα τέτοιο είναι η ύπαρξη των περίφημων APIs (Application Programming Interface), που επιτρέπουν σε ένα βιομηχανικό λογισμικό να αλληλοεπιδρά με τρίτο κώδικα. Είναι δηλαδή θύρες μέσα από τις οποίες μπορεί το λογισμικό να στείλει και να λάβει πληροφορίες και εντολές. Επιτρέπουν σε κάποιον που έχει ασφαλή πρόσβαση σε αυτές, να δημιουργήσει γέφυρες με ένα τρίτο σύστημα, όπως ένα οπλικό σύστημα, έναν αισθητήρα, ή και ένα ολόκληρο CMS άλλου προμηθευτή.

Η ύπαρξη APIs από μόνη της δεν είναι καθοριστική. Έχει σημασία αυτά τα APIs σε ποιο βαθμό «αγγίζουν» τις βασικές λειτουργίες του συστήματος κ.ο.κ. Όσο περισσότερο επενδύσει ο κατασκευαστής στη συγγραφή APIs που να δίνουν πρόσβαση σε πολλές αν όχι όλες τις λειτουργίες του συστήματος, τόσο πιο «ανοικτής αρχιτεκτονικής» είναι τελικά το λογισμικό.

Έχει σημασία επίσης τί είδους APIs είναι αυτά (πχ. RESTful APIs) και πόσο εύκολο είναι για κάποιον τρίτο να γράψει επάνω τους. Αν ο κατασκευαστής επιθυμεί να φτιάξει ένα πραγματικά ανοικτό σύστημα, τότε ενδεχομένως να αναπτύξει και Integration Frameworks για τα APIs του, που να επιτρέπουν σε προγραμματιστές να χρησιμοποιήσουν κάποιο ευρέως διαδεδομένο πρωτόκολλο (OpenAPISpecification), να λαμβάνει έτοιμες μεθόδους συγχρονισμού σκριπταρισμένες σε JSON αρχεία, να έχει πλήρες documentation και development resources κ.ο.κ. Υπάρχουν πάρα πολλά που μπορεί να κάνει ένας κατασκευαστής, με επιπλέον κόστος για τον ίδιο, εφόσον εμπορικά κρίνει ότι είναι προς το συμφέρον του το σύστημά του να είναι ανοικτής αρχιτεκτονικής.

Γιατί να επενδύσει ο κατασκευαστής CMS σε ανοικτή αρχιτεκτονική;

Στα συστήματα ανοικτής αρχιτεκτονικής η λογική είναι πως δημιουργείται ένα οικοσύστημα προγραμματιστών γύρω τους, οι οποίοι έχοντας σχετικά εύκολη πρόσβαση θα αναπτύξουν περιφερειακό λογισμικό που τρέχει γύρω από την πλατφόρμα (CMS). Παραδείγματα από τον χώρο των καταναλωτικών λογισμικών είναι τα Google Play και App Store. Οι ίδιες οι εταιρίες δεν θα μπορούσαν, ούτε θα ήθελαν να αναπτύσσουν τις εκατομμύρια εφαρμογές που υπάρχουν για τις πλατφόρμες τους. Θεωρούν πως το οικοσύστημα θα το κάνει γρηγορότερα και καλύτερα.

Ο ρόλος της Ελληνικής βιομηχανίας

Στην Ελλάδα υπάρχουν αμυντικές εταιρίες με εξαιρετική τεχνογνωσία και εξειδίκευση που κερδίζουν συμβόλαια στο εξωτερικό. Υπάρχουν ελληνικής σχεδίασης και ανάπτυξης αισθητήρες (Ε/Ο, θερμικοί) που βρίσκονται πάνω σε πλοία του ΠΝ. Υπάρχει VTOL ΜΕΑ ναυτικής συνεργασίας που σχεδιάστηκε από ελληνική εταιρία και δοκιμάστηκε πάνω σε πλοία του ΠΝ, το ίδιο και για USV. Υπάρχει εταιρία ανάπτυξης ολοκληρωμένων συστημάτων διοίκησης και ελέγχου η οποία, εκτός των άλλων, κατασκευάζει το εθνικό σύστημα ασφαλούς ζεύξης της Ινδονησίας (μιας χώρας εκτός ΝΑΤΟ που δεν έχει πρόσβαση στο Link-16). Όλες αυτές οι εταιρίες και πολλές άλλες θα μπορούσαν να αναπτύσσουν εξαιρετικά συστήματα για τον στόλο. Αρκεί να είχαν πρόσβαση στην καρδιά του πλοίου που λέγεται CMS. Διότι stand-alone συστήματα και όπλα στον 21^ο αιώνα δεν έχουν θέση.

ΕΞΕΛΙΞΗ: Η SIGMA 10514HN είναι “εδώ” με TACTICOS, η μόνη επιλογή αν το ΠΝ επιθυμεί ESSM Block 2

Εθνικό CMS

Έχουμε διαβάσει πολλά για εθνικά τυφέκια, εθνικά πλοία, άρματα, ΤΟΜΑ, κ.ο.κ. Μήπως η καλύτερη επένδυση για τα μέτρα της Ελλάδας (μικρή χώρα με οικονομία υπηρεσιών,  ανθρώπινους πόρους υψηλής κατάρτισης, σκληρό νόμισμα και υψηλό εργατικό κόστος) είναι ένα εθνικό CMS; Και τί θα πει εν τέλει «εθνικό CMS»; Να κάτσουμε να γράψουμε στην Ελλάδα από λευκή κόλλα ένα CMS; Όχι φυσικά. Οι άλλοι προηγούνται με τεχνογνωσία δεκαετιών.

Τα συστήματα που είναι διαθέσιμα στην αγορά διαθέτουν βιβλιοθήκες που ούτε έχουμε πρόσβαση για να γράψουμε, ούτε έχει νόημα να το κάνουμε αφού ήδη υπάρχουν. Θα μπορούσαμε όμως να επιλέξουμε ένα CMS ανοικτής αρχιτεκτονικής που θα αφορά σε μεγάλο αριθμό μονάδων του στόλου. Και να αρχίσουμε να χτίζουμε τεχνογνωσία πάνω σε αυτό με ελληνικές εταιρίες που θα αξίζει τον κόπο να επενδύσουν τον χρόνο των μηχανικών τους για να εξοικειωθούν με την τεχνολογία του. Θα μπορούσαν αυτές οι εταιρίες να δημιουργήσουν προϊόντα που να αφορούν στο ΠΝ αλλά και σε εξαγωγικούς πελάτες αφού θα είναι “plug ‘n’ play” για το συγκεκριμένο CMS.

Θα μπορούσαμε γύρω από αυτό το εθνικό CMS να χτίζουμε προδιαγραφές μελλοντικών διαγωνισμών, αντί να έρχεται ο κάθε υποψήφιος μνηστήρας με ότι έχει. Θα μπορούσαμε τέλος να κοιτάζουμε το μέλλον με αναπτυσσόμενη ναυτική βιομηχανία που δεν θα έχει καμία σχέση με το πού κόβονται οι λαμαρίνες, αλλά με το πού παράγεται η προστιθέμενη αξία. Όπως κάνουν οι Ισραηλινοί με τις δικές τους Saar 6, οι οποίες ναυπηγούνται στη Γερμανία αλλά ότι φορούν επάνω είναι ισραηλινής κατασκευής.

«Κορβετιάδα»: Το μεγάλο λάθος που δεν πρέπει να γίνει

Συμπέρασμα

Τα εξοπλιστικά διλήμματα της Ελλάδας την τελευταία διετία επιβαρύνονται από το στοιχείο του “κατεπείγοντος”. Μετά από μια μακρά περίοδο οικονομικής ύφεσης, σκληρής λιτότητας και αυτοαφοπλισμού, βρεθήκαμε μπροστά σε έναν εξαιρετικά αποθρασυμένο γείτονα που αναθεωρεί τα πάντα. Είναι κατανοητό και αναμενόμενο πως πολλές επιλογές αναγκαστικά θα γίνουν με βάση το “τώρα” και εις βάρος του “αύριο”. Στο βαθμό όμως που είναι δυνατόν, καλό θα ήταν να κρατήσουμε ένα μάτι ανοιχτό και προς το αύριο και να μην επαναλάβουμε τα λάθη του παρελθόντος με τις σπασμωδικές προμήθειες χωρίς προγραμματισμό και συνέχεια. Το θέμα CMS είναι ίσως κομβικότερο σε αυτή τη συζήτηση. Όποιες και αν είναι οι επιλογές μας τελικά, ας έχουμε γνώση τί ευκαιρίες μπορούν να μας δώσουν στο μέλλον ή τί αδιέξοδα μπορούν να γεννήσουν.

⁽¹⁾ Aboard a warship, the job of the Combat Management System (CMS) is to gather, integrate and present information from the ship’s own sensors and from external sources pertaining to unknown, hostile, neutral and friendly targets, and to enable the crew to act upon such information. Πηγή.