Πώς να σχεδιάζετε βιομηχανικές εφαρμογές ανθεκτικές σε προσωρινή απώλεια δικτύου, επανεκκίνηση συσκευών και διακοπή της σύνδεσης;

Η ανθεκτικότητα μιας βιομηχανικής εφαρμογής σε στιγμιαία απώλεια δικτύου, επανεκκίνηση συσκευών και διακοπή σύνδεσης δεν αποτελεί πλέον ένα πρόσθετο στοιχείο που απλώς βελτιώνει την άνεση χρήσης, αλλά προϋπόθεση για τη σωστή λειτουργία της διεργασίας και για τη διατήρηση της ευθύνης από την πλευρά του κατασκευαστή, του integrator ή του τελικού χρήστη. Σε βιομηχανικό περιβάλλον, η απώλεια επικοινωνίας δεν είναι κάτι ασυνήθιστο: εμφανίζεται κατά τη διάρκεια εργασιών συντήρησης, κατά τις μεταγωγές της υποδομής, στην εκκίνηση μετά από διακοπή τροφοδοσίας, σε ενημερώσεις, σε υπερφόρτωση του δικτύου ή ακόμη και σε μια απλή βλάβη συσκευής πεδίου. Αν σε τέτοιες συνθήκες η εφαρμογή χάνει τη συνοχή της κατάστασης, διπλοεκτελεί εντολές ή, μετά την αποκατάσταση της σύνδεσης, εκτελεί εκκρεμείς λειτουργίες χωρίς έλεγχο του πλαισίου, τότε το πρόβλημα παύει να είναι αποκλειστικά πληροφορικό. Μετατρέπεται σε ζήτημα συνέχειας της διεργασίας, λειτουργικής ασφάλειας, ποιότητας των δεδομένων παραγωγής και ιχνηλασιμότητας των σχεδιαστικών αποφάσεων.

Γι’ αυτό το θέμα απαιτεί αποφάσεις από την αρχή του έργου και όχι μετά την πρώτη εκκίνηση. Μια αρχιτεκτονική ανθεκτική σε διακοπές επικοινωνίας επηρεάζει τον τρόπο μοντελοποίησης των καταστάσεων της μηχανής, τους κανόνες προσωρινής αποθήκευσης δεδομένων, τη σειρά επιβεβαίωσης των εντολών, τις προϋποθέσεις επανασύστασης της συνεδρίας και τη λογική επιστροφής σε λειτουργία μετά από επανεκκίνηση. Αν η ομάδα αναβάλει αυτές τις αποφάσεις, συνήθως καταλήγει σε δαπανηρές παρακάμψεις: τοπική προσθήκη εξαιρέσεων, χειροκίνητο καθαρισμό ουρών, πρόσθετες δεσμεύσεις για τον χειριστή ή επέκταση του εποπτικού επιπέδου μόνο και μόνο για να αντισταθμιστεί η έλλειψη προβλέψιμης συμπεριφοράς των συσκευών. Το πρακτικό κριτήριο αξιολόγησης είναι απλό: για κάθε ουσιώδη λειτουργία πρέπει να μπορεί να δοθεί σαφής απάντηση στο τι θα συμβεί σε περίπτωση απώλειας επικοινωνίας, τι θα συμβεί μετά από επανεκκίνηση και ποιος επιβεβαιώνει την επανέναρξη της λειτουργίας. Αν η απάντηση είναι «εξαρτάται από την υλοποίηση» ή «ο χειριστής θα δει ότι κάτι δεν πάει καλά», τότε δεν υπάρχει ακόμη σχεδιαστική απόφαση, αλλά μεταφορά του κινδύνου στη λειτουργία.

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

Από διοικητική και κανονιστική σκοπιά, το κρίσιμο ζήτημα δεν είναι λοιπόν αν οι διακοπές επικοινωνίας «συμβαίνουν», αλλά αν ο σχεδιασμός μπορεί να αποδείξει ασφαλή και προβλέψιμη συμπεριφορά σε τέτοιες οριακές καταστάσεις. Αυτό είναι και το κατάλληλο σημείο όπου το θέμα περνά στην πρακτική αξιολόγηση κινδύνου: πρέπει να διαχωριστούν οι λειτουργίες για τις οποίες είναι αποδεκτή μια καθυστέρηση ή η απώλεια μέρους των ιστορικών δεδομένων από εκείνες στις οποίες η απώλεια του πλαισίου μπορεί να οδηγήσει σε λανθασμένη απόφαση του χειριστή, σε ζημιά του προϊόντος ή σε κίνδυνο κατά την επανεκκίνηση. Αξίζει να μετρώνται όχι αφηρημένοι δείκτες «σταθερότητας του συστήματος», αλλά δείκτες που αποτυπώνουν τις σχεδιαστικές συνέπειες: ο αριθμός αμφίσημων επανεκκινήσεων μετά από restart, ο αριθμός εντολών που απαιτούν χειροκίνητη συμφωνία της κατάστασης, ο χρόνος που απαιτείται για ασφαλή επιστροφή σε λειτουργία και οι περιπτώσεις στις οποίες το σύστημα δεν μπορεί να αποδείξει αν η εντολή εκτελέστηκε. Μόνο σε αυτό το πλαίσιο αποκτούν νόημα οι κανονιστικές απαιτήσεις και οι αποφάσεις για τεχνικά μέτρα: ανάλυση των συνθηκών εκκίνησης μετά από διακοπή τροφοδοσίας, αξιολόγηση κινδύνου για σενάρια απώλειας επικοινωνίας και επιλογή λύσεων αλληλοασφάλισης και εποπτείας εκεί όπου ο ίδιος ο μηχανισμός πληροφορικής δεν παρέχει επαρκή βεβαιότητα.

Πού αυξάνεται συχνότερα το κόστος ή ο κίνδυνος

Στα έργα σχεδιασμού βιομηχανικών εφαρμογών ανθεκτικών σε διαταραχές επικοινωνίας και επανεκκινήσεις συσκευών, το κόστος συνήθως δεν αυξάνεται λόγω των ίδιων των τεχνικών μηχανισμών, αλλά εξαιτίας λανθασμένων παραδοχών για την κατάσταση της διεργασίας μετά από μια διαταραχή. Αν η ομάδα θεωρήσει ότι μετά την αποκατάσταση της επικοινωνίας το σύστημα «θα επιστρέψει στην κανονική λειτουργία», αργά ή γρήγορα θα πληρώσει το τίμημα με χειροκίνητη συμφωνία καταστάσεων, διορθώσεις στη λογική ελέγχου, πρόσθετες δοκιμές παραλαβής ή λειτουργικούς περιορισμούς που επιβάλλονται αφού το σύστημα έχει ήδη τεθεί σε λειτουργία. Οι πιο δαπανηρές περιπτώσεις είναι εκείνες στις οποίες η εφαρμογή δεν μπορεί να απαντήσει με σαφήνεια αν μια εντολή εκτελέστηκε, διακόπηκε, διπλοεκτελέστηκε ή απλώς καταγράφηκε στην πλευρά της διεπαφής. Αυτό δεν είναι ζήτημα ευχρηστίας, αλλά ευθύνης για το φυσικό αποτέλεσμα: την κίνηση του άξονα, την αλλαγή ρύθμισης, το άνοιγμα βαλβίδας, την επιβεβαίωση συναγερμού ή την επανέναρξη του κύκλου.

Πηγή καθυστερήσεων στο έργο είναι συχνά και η εσφαλμένη κατανομή ευθυνών ανάμεσα στο επίπεδο χειριστή, την ενδιάμεση εφαρμογή και τον έλεγχο της μηχανής. Αν η απόφαση για το τι πρέπει να συμβαίνει μετά από επανεκκίνηση αφεθεί «για την υλοποίηση», η ομάδα συνήθως καταλήγει με ασυνεπείς κανόνες: το πάνελ εμφανίζει την τελευταία γνωστή κατάσταση, ο ελεγκτής εκκινεί διαδικασία αρχικοποίησης και το ανώτερο σύστημα επαναφέρει εκκρεμείς εντολές χωρίς βεβαιότητα ότι εξακολουθούν να είναι έγκυρες. Στην πράξη αυτό πρέπει να αποσαφηνίζεται νωρίτερα και ρητά: ποιες λειτουργίες μπορούν να επαναληφθούν χωρίς παρενέργειες, ποιες απαιτούν επιβεβαίωση των τρεχουσών συνθηκών του εξοπλισμού και ποιες, μετά από απώλεια επικοινωνίας, πρέπει να λήγουν και να μεταβαίνουν σε ασφαλή κατάσταση. Ένα καλό κριτήριο λήψης απόφασης είναι απλό: αν η εσφαλμένη επανέναρξη μιας λειτουργίας μπορεί να μεταβάλει την ενεργειακή κατάσταση, τη θέση ενός ενεργοποιητή, την ποιότητα του προϊόντος ή τις συνθήκες ασφάλειας των ανθρώπων, τότε δεν επιτρέπεται να βασιζόμαστε αποκλειστικά στη μνήμη της τελευταίας κατάστασης της εφαρμογής.

Αυτό φαίνεται καθαρά στο παράδειγμα μιας ακολουθίας που, πριν από τη διακοπή της επικοινωνίας, έστειλε εντολή για κλείσιμο του προστατευτικού και έναρξη του κύκλου, ενώ μετά την επανεκκίνηση του σταθμού χειριστή επαναφέρει την οθόνη «ετοιμότητα για λειτουργία». Αν η εφαρμογή δεν διακρίνει μεταξύ των καταστάσεων «εντολή αποδεκτή», «εκτέλεση επιβεβαιωμένη», «εκτέλεση διακοπείσα», «ακαθόριστη κατάσταση», ο χειριστής λαμβάνει μια εικόνα φαινομενικά συνεπή, αλλά στην πράξη ελλιπή. Η συνέπεια μπορεί να είναι περιττές διακοπές, επειδή το προσωπικό φοβάται να επανεκκινήσει τη διαδικασία, ή το αντίθετο: μη εξουσιοδοτημένη εκκίνηση, επειδή η διεπαφή δεν δείχνει ότι απαιτείται νέα επαλήθευση. Για τον υπεύθυνο έργου αυτό σημαίνει αργότερα δαπανηρή διερεύνηση αιτίων, αλλαγή των σεναρίων δοκιμών και ανάγκη προσθήκης διαδικασιών παράκαμψης. Για τον ιδιοκτήτη του προϊόντος σημαίνει κίνδυνο παραπόνων και διαφωνιών ως προς το εύρος της ευθύνης, ιδίως όταν η τεκμηρίωση απαιτήσεων δεν καθορίζει με σαφήνεια τη συμπεριφορά του συστήματος μετά από απώλεια τροφοδοσίας ή επικοινωνίας. Γι’ αυτό αξίζει να μετρώνται όχι μόνο η διαθεσιμότητα, αλλά και ο αριθμός των ακαθόριστων καταστάσεων μετά από επανεκκίνηση, ο αριθμός των λειτουργιών που απαιτούν χειροκίνητο συντονισμό και ο χρόνος μέχρι την επίτευξη ασφαλούς ετοιμότητας.

Ξεχωριστή κατηγορία κόστους είναι η σύγχυση της ανθεκτικότητας της επικοινωνίας με τη λειτουργική ασφάλεια. Το γεγονός και μόνο ότι η εφαρμογή μπορεί να αποθηκεύει δεδομένα σε buffer, να επαναλαμβάνει τη μετάδοση ή να αποκαθιστά μια συνεδρία δεν σημαίνει ακόμη ότι η μηχανή θα συμπεριφερθεί με ασφάλεια μετά από απώλεια σύνδεσης. Όταν οι συνέπειες της διαταραχής επηρεάζουν λειτουργίες που σχετίζονται με την κίνηση, την αποθηκευμένη ενέργεια, τις διατάξεις αλληλοασφάλισης ή τις συνθήκες επανεκκίνησης, το θέμα περνά φυσικά στην πρακτική εκτίμηση κινδύνου. Τότε πρέπει να εξετάζεται όχι μόνο η πιθανότητα αστοχίας του δικτύου, αλλά κυρίως οι πιθανές συνέπειες από εσφαλμένη πληροφορία κατάστασης και από εσφαλμένη επανέναρξη. Αν το σύστημα περιλαμβάνει υδραυλικά, προστίθενται και οι απαιτήσεις που αφορούν τη συμπεριφορά των ενεργοποιητών σε περίπτωση απώλειας τροφοδοσίας και πτώσης πίεσης· εκεί οι αποφάσεις σε επίπεδο εφαρμογής δεν μπορούν να έρχονται σε αντίθεση με τις αρχές σχεδιασμού που ισχύουν για τα υδραυλικά συστήματα. Αντίστοιχα, όπου η αποκατάσταση της ετοιμότητας εξαρτάται από το κλείσιμο του προστατευτικού ή την απελευθέρωση της ασφάλισης, το πρόβλημα μπορεί να επεκταθεί και στον τομέα των διατάξεων αλληλοασφάλισης και της αντοχής στην παράκαμψη των μέτρων προστασίας, επειδή η πίεση για «γρήγορη επανέναρξη» γεννά πολύ συχνά αργότερα επικίνδυνες πρακτικές λειτουργίας.

Η αναφορά σε κανονιστικές απαιτήσεις έχει νόημα μόνο σε αυτό το στάδιο, όταν είναι ήδη γνωστό ποιο σενάριο επιφέρει τεχνικές και οργανωτικές συνέπειες. Αν η απώλεια σύνδεσης ή η επανεκκίνηση μπορούν να αλλάξουν τις συνθήκες ασφαλούς εκκίνησης, αυτό πρέπει να περιγραφεί στην ανάλυση κινδύνου και να μη μείνει ως προεπιλεγμένη συμπεριφορά του κατασκευαστή λογισμικού ή του προμηθευτή του ελεγκτή. Αν το εκτελεστικό σύστημα μπορεί, μετά από απώλεια τροφοδοσίας, να λάβει κατάσταση δυσμενή για τη διεργασία ή επικίνδυνη, πρέπει να ελεγχθεί αν οι απαιτήσεις για το συγκεκριμένο είδος κίνησης και μέσου επιβάλλουν πρόσθετα κατασκευαστικά μέτρα, ανεξάρτητα από τη λογική της εφαρμογής. Ένα πρακτικό οριακό κριτήριο είναι το εξής: όταν ένα σφάλμα μετά την αποκατάσταση της κατάστασης μπορεί να εξαλειφθεί αποκλειστικά με διαδικασία χειριστή, τότε το θέμα δεν είναι πλέον μόνο πληροφορικής, αλλά και σχεδιασμού και συμμόρφωσης. Ακριβώς σε αυτό το σημείο η απόφαση για την αρχιτεκτονική της εφαρμογής παύει να είναι ζήτημα ευκολίας υλοποίησης και γίνεται στοιχείο ευθύνης για την ασφαλή και προβλέψιμη συμπεριφορά ολόκληρου του συστήματος.

Πώς να προσεγγίσετε το θέμα στην πράξη

Στην πράξη, η ανθεκτικότητα μιας βιομηχανικής εφαρμογής σε προσωρινή απουσία δικτύου, επανεκκίνηση συσκευών και απώλεια σύνδεσης δεν ξεκινά από την επιλογή τεχνολογίας, αλλά από την απόφαση για το ποιες συνέπειες μιας αστοχίας είναι αποδεκτές και ποιες όχι. Η ομάδα πρέπει εξαρχής να διαχωρίσει τρία πράγματα: την κατάσταση της διεργασίας, την κατάσταση του ελέγχου και την κατάσταση που παρουσιάζεται στον χειριστή. Αυτή η διάκριση καθορίζει αν, μετά από διακοπή της επικοινωνίας, η εφαρμογή πρέπει απλώς να αποκαταστήσει την απεικόνιση ή αν έχει δικαίωμα να επαναλάβει τον έλεγχο, την ουρά εντολών ή την τεχνολογική ακολουθία. Αν αυτά τα επίπεδα συγχωνευθούν σε ένα, το έργο συνήθως καταλήγει σε δαπανηρή προσθήκη εξαιρέσεων, χειροκίνητες διαδικασίες παράκαμψης ή διαφωνία ως προς την ευθύνη μετά τη θέση σε λειτουργία. Για τον manager εδώ έχει σημασία ένα πράγμα: η απουσία ρητής αρχιτεκτονικής απόφασης δεν μειώνει τον κίνδυνο, αλλά τον μεταφέρει στο στάδιο των παραλαβών, της συντήρησης και της συμμόρφωσης.

Σε επιχειρησιακό επίπεδο, αυτό σημαίνει ότι για κάθε κρίσιμη περίπτωση πρέπει να οριστεί τι ακριβώς οφείλει να διατηρεί το σύστημα μετά από μια διαταραχή και τι δεν επιτρέπεται να διατηρεί. Δεν αρκεί η γενική διατύπωση «να συνεχίζει να λειτουργεί μετά το reconnect», αλλά απαιτούνται σαφείς κανόνες: ποια δεδομένα αποκαθίστανται από μόνιμη αποθήκευση, ποια πρέπει να επιβεβαιώνονται από τη συσκευή, ποιες εντολές παύουν να ισχύουν μετά την παρέλευση συγκεκριμένου χρόνου και ποιες απαιτούν νέα εξουσιοδότηση ή επιβεβαίωση από τον χειριστή. Ένα σωστό κριτήριο λήψης απόφασης είναι απλό: αν μετά από επανεκκίνηση δεν μπορεί να διαπιστωθεί με σαφήνεια αν μια προηγούμενη εντολή εκτελέστηκε, το σύστημα δεν πρέπει να την εκτελεί ξανά αυτόματα. Το ίδιο ισχύει για συναγερμούς, μετρητές παρτίδων, τρόπους λειτουργίας και τεχνολογικές αλληλοασφαλίσεις. Μια τέτοια πρόβλεψη μπορεί να φαίνεται ως μικρή σχεδιαστική λεπτομέρεια, αλλά χωρίς αυτήν αυξάνεται το κόστος των δοκιμών ολοκλήρωσης, επειδή κάθε ασάφεια επιστρέφει ως σφάλμα που είναι δύσκολο να αναπαραχθεί. Αυξάνεται επίσης η ευθύνη από την πλευρά του ιδιοκτήτη της λύσης, επειδή αργότερα πρέπει να αποδειχθεί ότι η συμπεριφορά μετά από απώλεια επικοινωνίας ήταν προβλέψιμη και σκόπιμα καθορισμένη.

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

Το όριο με την ανάλυση κινδύνου εμφανίζεται όταν η εσφαλμένη αποκατάσταση της κατάστασης μπορεί να αλλάξει τη συμπεριφορά της μηχανής, της ακολουθίας ή του εκτελεστικού συστήματος. Σε μια τέτοια περίπτωση, το θέμα παύει να είναι αποκλειστικά πληροφορικό και περνά στο πεδίο της πρακτικής εκτίμησης κινδύνου, επίσης με την έννοια της μεθοδολογίας που εφαρμόζεται στο ISO/TR 14121-2. Αν, μετά από διακοπή τροφοδοσίας ή επανεκκίνηση της συσκευής, υπάρχει δυνατότητα αυτόματης επανέναρξης της κίνησης, παροχής μέσου, απελευθέρωσης εκτελεστικού στοιχείου ή μετάβασης σε τρόπο λειτουργίας χωρίς συνειδητή συναίνεση του χειριστή, τότε το ζήτημα αφορά και την προστασία από απροσδόκητη εκκίνηση, κάτι που απαιτεί ευρύτερη θεώρηση από τη λογική της ίδιας της εφαρμογής. Όπου υπάρχουν υδραυλικές ή πνευματικές κινήσεις, προστίθενται και κατασκευαστικές απαιτήσεις καθώς και η συμπεριφορά του συστήματος μετά από απώλεια ενέργειας, επομένως η απόφαση για «ήπια» επανέναρξη λειτουργίας δεν μπορεί να αποσυνδέεται από τις τεχνικές συνθήκες ολόκληρης της εγκατάστασης. Από την άποψη της συμμόρφωσης, η ασφαλέστερη προσέγγιση είναι να μην επιχειρείται εικασία για την πρόθεση της διεργασίας μετά από διαταραχή, αλλά να καθορίζονται εκ των προτέρων οι όροι επιστροφής στη λειτουργία και να αποδίδονται σε συγκεκριμένες ευθύνες: της εφαρμογής, του ελεγκτή, του εκτελεστικού συστήματος και του χειριστή.

Τι να προσέξετε κατά την υλοποίηση

Τα περισσότερα σφάλματα κατά την υλοποίηση βιομηχανικών εφαρμογών ανθεκτικών σε στιγμιαία απώλεια δικτύου, επανεκκίνηση συσκευών και απώλεια σύνδεσης δεν προκύπτουν από την ίδια την τεχνολογία, αλλά από λανθασμένη κατανομή ευθυνών. Η ομάδα θεωρεί ότι την «ανθεκτικότητα» θα τη λύσει το επίπεδο επικοινωνίας, ο πάροχος cloud ή ο ελεγκτής, ενώ στην πραγματικότητα το πρόβλημα βρίσκεται στη σχέση μεταξύ της κατάστασης της διεργασίας, της κατάστασης της συσκευής και της κατάστασης των δεδομένων. Αν αυτές οι τρεις διαστάσεις δεν διαχωριστούν ήδη από το στάδιο της παραλαβής, το έργο αρχίζει να παράγει μια επίφαση αξιοπιστίας: η εφαρμογή λειτουργεί μετά από νέα εκκίνηση, αλλά κανείς δεν μπορεί να αποδείξει αν μετά την επανεκκίνηση αποκατέστησε σωστή, ασφαλή και σύμφωνη με τη φυσική πραγματικότητα κατάσταση. Αυτό επηρεάζει άμεσα το κόστος, επειδή οι μεταγενέστερες διορθώσεις συνήθως απαιτούν αλλαγές ταυτόχρονα στη λογική ελέγχου, στη διεπαφή χειριστή, στην καταγραφή συμβάντων και στις διαδικασίες εκκίνησης. Επηρεάζει επίσης την ευθύνη, επειδή σε περίπτωση συμβάντος είναι δύσκολο να υποστηριχθεί μια λύση στην οποία δεν έχει οριστεί με σαφήνεια ποιος και με ποια βάση επιβεβαιώνει την ετοιμότητα για επανέναρξη της λειτουργίας.

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

Ένα χαρακτηριστικό παράδειγμα είναι ένας σταθμός που, μετά από στιγμιαία απώλεια επικοινωνίας, χάνει τη σύνδεση με το ανώτερο σύστημα, αλλά τοπικά εξακολουθεί να «βλέπει» μέρος των σημάτων εισόδου. Από την οπτική του προγράμματος, είναι δελεαστικό να «ολοκληρωθεί η ακολουθία» μόλις επανέλθει η σύνδεση, ώστε να μη χαθεί χρόνος κύκλου. Το πρόβλημα αρχίζει όταν, στο μεταξύ, ο χειριστής έχει αφαιρέσει το τεμάχιο, έχει ενεργοποιηθεί βαλβίδα εκτόνωσης, έχει γίνει επανεκκίνηση του πίνακα χειρισμού ή η κίνηση έχει περάσει σε άλλη κατάσταση λειτουργίας. Στη λογική της εφαρμογής όλα μπορεί να φαίνονται συνεπή και παρ’ όλα αυτά η συνέχιση του βήματος να αποτελεί τεχνολογικό σφάλμα ή κίνδυνο. Γι’ αυτό, κατά την υλοποίηση, αξίζει να αξιολογείται όχι μόνο ο αριθμός των χαμένων επικοινωνιών ή ο χρόνος αποκατάστασης της συνεδρίας, αλλά και δείκτες που δείχνουν την ποιότητα της συμπεριφοράς μετά από διαταραχή: πόσες φορές το σύστημα απαίτησε χειροκίνητο επανασυγχρονισμό, πόσες λειτουργίες απορρίφθηκαν ως μη πλέον έγκυρες, πόσες επανεκκινήσεις κατέληξαν σε μετάβαση σε ασφαλή κατάσταση αντί για αυτόματη συνέχιση. Αυτοί είναι καλύτεροι δείκτες ωριμότητας της λύσης από την απλή διαθεσιμότητα της υπηρεσίας, επειδή αποκαλύπτουν αν η ανθεκτικότητα αποκτήθηκε εις βάρος του ελέγχου της διεργασίας.

Το όριο στο οποίο αυτό το θέμα παύει να είναι αποκλειστικά ζήτημα αρχιτεκτονικής εφαρμογής εμφανίζεται νωρίτερα απ’ όσο συνήθως υποθέτουν οι ομάδες έργου. Αν η απώλεια σύνδεσης, η επανεκκίνηση του ελεγκτή ή η αποκατάσταση της ουράς εργασιών μπορεί να επηρεάσει την κίνηση της μηχανής, την παροχή ενέργειας ή τη μεταβολή της κατάστασης ενός εκτελεστικού συστήματος, τότε το ζήτημα περνά στην πρακτική εκτίμηση κινδύνου. Σε αυτό το σημείο δεν αρκεί πλέον το επιχείρημα ότι η λύση «συνήθως λειτουργεί σωστά»· απαιτείται ανάλυση σεναρίων αποκλίσεων, ακόμη και με λογική κοντά στην προσέγγιση που εφαρμόζεται στο ISO/TR 14121-2. Αν επιπλέον, μετά την αποκατάσταση της τροφοδοσίας ή της επικοινωνίας, υπάρχει δυνατότητα αυτόματης επανέναρξης της λειτουργίας, τότε το θέμα αφορά και την προστασία από μη αναμενόμενη εκκίνηση και πρέπει να εξεταστεί ευρύτερα, σε συνάρτηση με τις συνθήκες εκκίνησης και την κατάσταση απομόνωσης της ενέργειας. Εκεί όπου το σύστημα περιλαμβάνει υδραυλικά ή πνευματικά, δεν είναι δυνατό να διαχωριστεί η προγραμματιστική απόφαση από τη συμπεριφορά της εγκατάστασης μετά από απώλεια ενέργειας· σε τέτοιες περιπτώσεις πρέπει να ελέγχονται και οι κατασκευαστικές απαιτήσεις που ισχύουν για το σύνολο του συστήματος, και όχι μόνο η ορθότητα του κώδικα της εφαρμογής.