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

Θα ξεκινήσω δηλώνοντας πως ο σκοπός αυτού του άρθρου δεν είναι να πριμοδοτήσει τη μια ή την άλλη υποψηφιότητα για τα νέα καράβια του ΠΝ. Ορμώμενος φυσικά από τις κεφαλαιώδους σημασίας εξοπλιστικές εξελίξεις για τη χώρα, αλλά και την καταιγιστική ειδησεογραφία, θέλω να θίξω το θέμα των Συστημάτων Διαχείρισης Μάχης (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 που δεν έχει ενημερωθεί εδώ και δύο χρόνια. Με δεδομένη τη συχνότητα εμφάνισης νέων απειλών (malware, ransomware κ.λπ.) είναι σαν να μην έχουμε καμία προστασία. Κάπως έτσι φαντάζεται ο γράφων το μέλλον των 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 και μετά να ξεκινήσει τη σχεδίαση μιας λύσης στο χαρτί. Σημειώστε πως μέχρι τώρα δεν έχει γράψει ούτε μια γραμμή κώδικα. Είμαστε ακόμα στη φάση της ανάλυσης, οι ανθρωποώρες βέβαια στο κοστολόγιο «τρέχουν».

Οι προκλήσεις που μπορεί να προκύψουν από την ανάλυση των δύο συστημάτων ίσως να είναι σημαντικές. Μπορεί να αφορούν στο Database Layer, δηλαδή στον τρόπο που αποθηκεύει το κάθε σύστημα τα δεδομένα. Για παράδειγμα, το σύστημα Alpha, θα μπορούσε να κρατάει σε έναν πίνακα της βάσης όλους τους εναέριους στόχους και για κάθε εγγραφή να έχει πεδία που να την χαρακτηρίζουν ως φιλική, εχθρική, μη αναγνωρισμένη, αφος, ΜΕΑ, Ε/Π, K/B, οτιδήποτε. Ενώ το σύστημα Bravo θα μπορούσε να έχει άλλη αρχιτεκτονική βάσης, πχ να κρατάει ξεχωριστούς πίνακες για τους φιλικούς, εχθρικούς, μη αναγνωρισμένους στόχους κ.ο.κ.. Οι διαφορές μπορεί επίσης να επεκτείνονται στο Application Layer, δηλαδή στον τρόπο που το λογισμικό με τη “λογική” του διαχειρίζεται και ενημερώνει τα δεδομένα. Για παράδειγμα, το σύστημα Alpha θα μπορούσε να αποθηκεύει κάθε ένα δευτερόλεπτο τη θέση ενός στόχου με τιμές Χ,Υ,Ζ. Ενώ το σύστημα Bravo να παρακολουθεί διεύθυνση και ταχύτητα και να αποθηκεύει μόνο τον χρόνο κάποιας μεταβολής σε αυτές τις τιμές. Τέλος, διαφορές μπορεί να υπάρχουν και στο API Layer, δηλαδή στον τρόπο που μπορούν τα δύο συστήματα να γεφυρώνονται με τον έξω κόσμο, όπως θα δούμε παρακάτω. Σε κάθε περίπτωση, ο εργολήπτης θα πρέπει να σχεδιάσει λύσεις για κάθε τέτοιου είδους διαφορά.

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

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

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

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

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

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

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

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

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

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

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

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

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

Στην περίπτωση ενός CMS, το οικοσύστημα αποτελείται στην πραγματικότητα από τους ίδιους του κατασκευαστές όπλων και αισθητήρων, οι οποίοι έχουν κάθε λόγο να ολοκληρώσουν τα προϊόντα τους με μια εύκολη και δημοφιλή πλατφόρμα, αλλά και system integrators οι οποίοι θα μπορούν να αναλαμβάνουν έργα για λογαριασμό των τελευταίων ή των χρηστών του CMS, όπως το Πολεμικό Ναυτικό.

Η ανάγκη για συνεχείς αναβαθμίσεις

Στα μαχητικά αεροσκάφη είμαστε ίσως πιο συνηθισμένοι στην έννοια της αναβάθμισης λογισμικού, χωρίς επεμβάσεις στο hardware. Το ίδιο ραντάρ και ο ίδιος υπολογιστής μπορεί να αποδώσουν καλύτερα αποτελέσματα εντοπισμού και ταυτοποίησης στόχων με μια αναβάθμιση του λογισμικού που θα περιλαμβάνει νεότερες βιβλιοθήκες, φίλτρα, σύνδεση με ατρακτίδια κ.ο.κ.. Το ίδιο ισχύει φυσικά και για ένα πλοίο. Πόσο γρήγορα όμως μπορεί να προκύψει μια τέτοια ανάγκη; Σίγουρα γρηγορότερα από την ανάγκη αναβάθμισης του hardware. Όπως αναβαθμίζουμε το λειτουργικό του κινητού μας πολλές φορές πριν αλλάξουμε συσκευή, έτσι και το ραντάρ AESA σταθερών διατάξεων, οι οπτικές ίνες και οι τοπικοί ελεγκτές του πλοίου θα παραμείνουν επίκαιρα για δεκαετίες – το λογισμικό όμως όχι. Καθώς θα γίνονται διαθέσιμα δεδομένα από νέου τύπου απειλές, όπως υπερηχητικά ΜΕΑ, υπερηχητικοί αντιπλοϊκοί, νέφη μικρών drones ή/και loittering munitions κ.ο.κ., είναι σχεδόν σίγουρο πως το λογισμικό του κατά τα άλλα πανίσχυρου ραντάρ θα μπορούσε να βελτιωθεί με τις νέες αυτές πληροφορίες και έννοιες. Τί θα συμβεί τότε;

1. Ο κατασκευαστής του ραντάρ θα κάνει διαθέσιμη την νέα έκδοση του λογισμικού. Το ΠΝ θα ενδιαφερθεί φυσικά για την απόκτησή του.
2. Ο κατασκευαστής του CMS θα πρέπει να ενημερώσει το δικό του λογισμικό. Είναι μάλλον απίθανο πως η παλαιότερη έκδοση που αγοράσαμε θα καταννοεί τις νέες έννοιες που εισήγαγε το ραντάρ.
3. Σαν να μην έφτανε αυτό, κατασκευαστής του CMS θα πρέπει να ενημερώσει και τα APIs του σχετικά με αυτές τις νέες έννοιες. Ώστε να μπορεί ο οποιοσδήποτε τρίτος έχει ολοκληρωθεί με το CMS να τις διαβάσει επίσης. Κάποιος κατασκευαστής με νοοτροπία ανοικτής αρχιτεκτονικής θα το θεωρήσει εκ των ουκ άνευ. Κάποιος που ασχολείται περιστασιακά με τα APIs (δηλαδή, μόνον όταν το απαιτήσει ο πελάτης) μάλλον δεν θα το κάνει από μόνος του. Κάποιος κατασκευαστής που δεν έχει APIs δεν θα ασχοληθεί καν.
4. Και αν όλα πάνε καλά στα βήματα 1-3, δεν τελειώσαμε. Ο εντολοδόχος που έγραψε την ολοκλήρωση των CMS Alpha & Bravo, ή του Alpha με τα ΑΦΝΣ, ή με το ψηφιακό κέντρο του ΠΝ, κ.ο.κ., θα πρέπει να ενημερώσει και αυτός τον κώδικά του για αυτές τις νέες έννοιες. Ώστε να τις “βλέπει” τελικά το ΠΝ στο δίκτυό του.

Γίνεται λοιπόν κατανοητό ότι οι διασυνδεδεμένες επιχειρήσεις δεν θα πραγματοποιηθούν ποτέ με CMS μονάδων το λογισμικό των οποίων έχει να ανανεωθεί 20 χρόνια. Χωρίς συμβάσεις που να προβλέπουν υποστήριξη και αναβαθμίσεις του λογισμικού, χωρίς έργα ολοκλήρωσης που να προβλέπουν και ετήσιο κόστος συντήρησης/ενημέρωσης του κώδικα από τον ανάδοχο, θα βρισκόμαστε διαρκώς προ αδιεξόδων – με πανσπερμία ασύνδετων συστημάτων, ακόμα και αν είναι από τον ίδιο προμηθευτή.

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

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

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

Εθνικό CMS

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

Τα συστήματα που είναι διαθέσιμα στην αγορά…

Η συνέχεια στο Naval Defence