· Web viewΈντυπο FAL 7: Δηλωτικό επικινδύνων φορτίων Ναυτιλιακό δηλωτικό υγείας Πέραν των παραπάνω, ως

ΥΝΑ/ΑΛΣ-ΕΛ.ΑΚΤ

Τεχνικές προδιαγραφές έργου

«Μελέτη και Ανάπτυξη

Εθνικής Ενιαίας Ναυτιλιακής Θυρίδας»

Προϋπολογισμός Έργου: 2.197.000,00€

Προϋπολογισμός Δικαιωμάτων Προαίρεσης: 140.000,00€

Συνολικός Προϋπολογισμός: 2.337.000,00€

(Συμπεριλαμβανομένου Φ.Π.Α.)

Έργο ΑΝΝΑ

Περιεχόμενα

ΚΕΦΑΛΑΙΟ 1: Εισαγωγή 7

1.1. Υποβολή αναφορών σύμφωνα με την οδηγία 2010/65/ΕΕ.....................................7

1.2. Βασικές απαιτήσεις οδηγίας 2010/65/ΕΕ................................................................8

1.2.1. Διαβίβαση διατυπώσεων υποβολής δηλώσεων με ηλεκτρονικό μορφότυπο8

1.2.2. Δήλωση πληροφοριών μια φορά 8

1.2.3. Διαδικασίες ανταλλαγής δεδομένων 9

1.2.4. Συμβατότητα με υφιστάμενους κανόνες για την κοινοποίηση πληροφοριών πριν τον κατάπλου 10

1.2.5. Προστασία προσωπικών, εμπιστευτικών και εμπορικών δεδομένων 10

1.3. Υφιστάμενη κατάσταση υποβολής αναφορών......................................................10

1.4. Υφιστάμενα συστήματα για υποβολή αναφορών.................................................10

1.4.1. ICISnet 10

1.4.2. SafeSeaNet 11

1.4.3. SIS II 12

1.4.4. Shipsan 13

ΚΕΦΑΛΑΙΟ 2: Γενική Αρχιτεκτονική 14

2.1. Γενική περιγραφή της αρχιτεκτονικής του συστήματος........................................14

2.1.1. Πιλοτικό έργο 1 16




2.2. Ασφάλεια (security) του συστήματος....................................................................20

2.3. Βασικές Αρχές για την ανάπτυξη του συστήματος................................................21

2.4. Γενικά σημεία για την ανάπτυξη του συστήματος................................................27

2.4.1. Γενικές Αρχές ανάπτυξης του συστήματος 27

2.4.2. Τρόπος ανάπτυξης 29

2.4.3. Περιβάλλοντα 29

2.4.4. Δομοστοιχεία λογισμικού 30

ΚΕΦΑΛΑΙΟ 3: Διακινούμενα δεδομένα 31

3.1. Μοντέλο Δεδομένων.............................................................................................31

3.2. Δομή μηνυμάτων...................................................................................................32

3.3. Απαιτήσεις Ομάδας eMS.......................................................................................32

Σελίδα 2 από 106

Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 4: Χρήστες Συστήματος 34

4.1. Πολιτική Δικαιωμάτων χρηστών συστήματος.......................................................34

4.2. Δημιουργία και διαχείριση βάσης δεδομένων πλοίων.........................................35

4.3. Κωδικοί UNECE/LOCODE.......................................................................................37

4.4. Διαδικασία δημιουργίας εξωτερικού χρήστη........................................................37

4.5. Χρήστες Φορέων που έχουν πρόσβαση στα δεδομένα της ενιαίας ναυτιλιακής θυρίδας...............................................................................................................................38

4.6. Διαδικασία δημιουργίας χρήστη Machine to Machine.........................................39

4.7. Ασφάλεια κωδικών................................................................................................39

ΚΕΦΑΛΑΙΟ 5: Πιλοτικό έργο 1 - Front Office 41

5.1. Εισαγωγή...............................................................................................................41

5.2. Γενική αρχιτεκτονική.............................................................................................41

5.3. Λειτουργικές απαιτήσεις του GUI..........................................................................42

5.4. Μαζική εισαγωγή..................................................................................................45

5.5. Ταχύτητα απόκρισης.............................................................................................45

5.6. Ροή καταχώρησης..................................................................................................46

5.7. Διενέργεια ελέγχων κατά την καταχώρηση...........................................................46

ΚΕΦΑΛΑΙΟ 6: Πιλοτικό έργο 2 - Mid Office 48

6.1. Εισαγωγή...............................................................................................................48

6.2. Αρχιτεκτονική........................................................................................................48

6.3. Χειρισμός Μηνυμάτων..........................................................................................48

6.4. Απαιτήσεις για εξασφάλιση αδιάκοπης λειτουργίας............................................50

6.5. Backup...................................................................................................................50

6.6. Έλεγχοι Μηνυμάτων..............................................................................................51

6.7. Back ends...............................................................................................................51

6.7.1. Υλοποίηση των back ends 52

6.7.2. Διαχείριση των backends 52

6.8. Χειρισμός Λαθών...................................................................................................53

6.9. Ροή εργασίας χειρισμού σφαλμάτων....................................................................53

ΚΕΦΑΛΑΙΟ 7: Πιλοτικό έργο 3 - Back Office 54

7.1. Γενικά.....................................................................................................................54

7.2. Διασύνδεση με το σύστημα ICISNet......................................................................54

7.2.1. Περιγραφή 54

7.2.2. Απαιτούμενα στοιχεία για τη διασύνδεση 55


Έργο ΑΝΝΑ

7.2.3. Μελέτη εφαρμογής 55

7.2.4. Δικαίωμα προαίρεσης 55

7.3. Διασύνδεση με το σύστημα SiS.............................................................................55


7.3.2. Απαιτούμενα στοιχεία για τη διασύνδεση 56


7.3.4. Δικαίωμα προαίρεσης 56

7.4. Διασύνδεση με το σύστημα SafeSeaNet................................................................57

7.4.1. Γενικά 57

7.4.2. Βασικές Υποχρεώσεις των Κρατών Μελών 58

7.4.3. Ανταλλασσόμενες πληροφορίες μεταξύ των Κρατών Μελών και μέθοδοι συλλογής τους από τις Αρμόδιες Αρχές 58

7.4.4. Βασικές Λειτουργικές Δυνατότητες 59

7.4.5. Μηχανισμός ανταλλαγής μηνυμάτων θαλασσίων συμβάντων 59

7.4.6. Πραγματοποίηση δοκιμών 60

7.4.7. Δίκτυο SafeSeaNet 60

7.5. Διασύνδεση με το σύστημα Shipsan......................................................................61



ΚΕΦΑΛΑΙΟ 8: Πιλοτικό έργο 4 – Διεπαφή ανάκτησης δεδομένων 62

8.1. Γενικά.....................................................................................................................62

8.2. Ασφάλεια...............................................................................................................62

8.3. Αναφορές...............................................................................................................62

8.4. Επιπλέον λειτουργικότητα για το SafeSeaNet.......................................................64

8.4.1. Μηχανισμός Αυτόματων Ελέγχων για εντοπισμό μη καταχωρημένων περιπτώσεων 64

8.4.2. Παρακολούθηση SafeSeaNet 64

8.5. Παρουσίαση πληροφοριών / στατιστικών............................................................65

ΚΕΦΑΛΑΙΟ 9: Υποσύστημα Διαχείρισης και Εποπτείας (Management & Monitoring - Μ&M) 66

9.1. Γενικά.....................................................................................................................66

9.2. Ασφάλεια...............................................................................................................66

9.3. Ενσωμάτωση / ολοκλήρωση εποπτείας................................................................66

9.4. Ειδοποιήσεις..........................................................................................................68

9.5. Διαχείριση.............................................................................................................68


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 10: Εξοπλισμός 70

10.1. Application Delivery Controller (ADC) – Load Balancer (Καλύπτει το πιλοτικό 1)70

10.2. Blade Technology Server (Καλύπτει τα πιλοτικά 1-4 καθώς και το disaster recovery).............................................................................................................................71

10.2.1. Blade Chassis 71

10.2.2. Blade Servers 72

10.2.3. Λογισμικό Virtualization 73

10.3. Σύστημα κεντρικής αποθήκευσης δεδομένων (SAN) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery).........................................................................................74

10.4. Οπτικοί Μεταγωγείς Δεδομένων για το SAN (Optical SAN Switch) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)........................................................................76

10.5. Αυτοματοποιημένο Σύστημα Λήψης Αντιγράφων Ασφάλειας (Tape Library System) (Καλύπτει το πιλοτικό 2).......................................................................................78

10.6. Ικρίωμα (Rack) (Καλύπτει τα πιλοτικά 1-4 καθώς και το disaster recovery)........79

10.7. Μεταγωγείς δεδομένων για διαχείριση (Management Switches) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)........................................................................80

10.8. Εξυπηρετητές Διαχείρισης Συστημάτων Αποθήκευσης (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery).........................................................................................81

10.9. Σταθεροί Προσωπικοί Υπολογιστές (PC) (Καλύπτει το πιλοτικό 1)......................83

10.10. Φορητοί Υπολογιστές (Καλύπτει το πιλοτικό 1)................................................86

10.11. Tablets (Καλύπτει το πιλοτικό 1).......................................................................88

10.12. Γενικές Απαιτήσεις.............................................................................................91

ΚΕΦΑΛΑΙΟ 11: Γενικοί Όροι 93

11.1. Μελέτη Εφαρμογής.............................................................................................93

11.2. Παράδοση............................................................................................................94

11.3. Εκπαίδευση.........................................................................................................95

11.4. Δοκιμές................................................................................................................95

11.5. Παραλαβή έργου.................................................................................................96

11.6. Χρονοδιάγραμμα Έργου......................................................................................96

11.7. Παρακολούθηση Έργου.......................................................................................97

11.8. Εγγύηση, Συντήρηση, Τεχνική Υποστήριξη..........................................................97

11.8.1. Εγγύηση Καλής Λειτουργίας 98

11.8.2. Προληπτική Συντήρηση 99

11.8.3. Τεχνική Υποστήριξη 99

11.9. Τήρηση Εγγυημένου Επιπέδου Υπηρεσιών – Διαθεσιμότητα - Ρήτρες.............102


Έργο ΑΝΝΑ

11.10. Οδηγίες Κατάρτισης Τεχνικών Προσφορών Υποψηφίων Αναδόχων...............103

11.11. Τεχνική – Επαγγελματική Κατάρτιση...............................................................104

11.12. Δικαίωμα Προαίρεσης.....................................................................................104

Λίστα Παραρτημάτων 106

I. ANNA MIG (Message Implementation Guide)..................................................106

II. ΑΝΝΑ Security Guidelines.................................................................................106

III. eMS Data Mapping and Functionalities Sub-Group Report...............................106

IV. eMS National Single Window Guidelines..........................................................106

V. SSN XML Messaging Reference Guide v3.00.....................................................106

VI. SafeSeaNet Incident Report Guidelines v1.91...................................................106


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 1: Εισαγωγή

Το Λιμενικό Σώμα – Ελληνική Ακτοφυλακή (εφεξής ΛΣ-ΕΛ.ΑΚΤ) πρόκειται να προχωρήσει στη δημιουργία μίας ηλεκτρονικής ενιαίας ναυτιλιακής θυρίδας για την υποβολή των διατυπώσεων υποβολής δηλώσεων, με σκοπό τη διευκόλυνση των θαλάσσιων μεταφορών.

Το νομικό υπόβαθρο για την υλοποίηση της ενιαίας ναυτιλιακής θυρίδας (maritime single window) τίθεται από την οδηγία 2010/65/ΕΕ του Ευρωπαϊκού Κοινοβουλίου και του Συμβουλίου, της 20ής Οκτωβρίου 2010, σχετικά με τις διατυπώσεις υποβολής δηλώσεων για τα πλοία κατά τον κατάπλου ή/και απόπλου από λιμένες των κρατών μελών και για την κατάργηση της οδηγίας 2002/6/ΕΚ. Η εν λόγω οδηγία ενσωματώθηκε στο εθνικό δίκαιο την 8η Νοεμβρίου 2012 με το ΠΔ 125/2012.

Με σκοπό την αποτελεσματική υλοποίηση της ενιαίας θυρίδας, η χώρα μας συμμετέχει στο έργο «ΑΝΝΑ» (Advanced National Networks for Administrations – Maritime Single Window) μαζί με 13 ακόμα κ-μ, υπό το συντονισμό της Ολλανδίας, σε συνεργασία με την Ευρωπαϊκή Επιτροπή (Το έργο ΑΝΝΑ είναι μία Δράση στο πλαίσιο του πολυετούς χρηματοδοτικού προγράμματος Motorways of the Sea (MoS) των Διευρωπαϊκών Δικτύων Μεταφορών (ΤΕΝ-Τ) όπου συμμετέχουν 14 κ-μ, 10 επιπλέον χώρες ως παρατηρητές και 10 ενδιαφερόμενοι Οργανισμοί ως παρατηρητές). Μέσω του ΑΝΝΑ, πρόκειται να υποστηριχτεί η εναρμονισμένη υλοποίηση των εθνικών ναυτιλιακών θυρίδων των συμμετεχόντων κ-μ, σύμφωνα με τις απαιτήσεις της οδηγίας 2010/65/ΕΕ, σε συνεργασία και με την Ομάδα Εμπειρογνωμόνων eMS που έχει συσταθεί από την Ε. Επιτροπή για την αντιμετώπιση των τεχνικών θεμάτων της εφαρμογής της οδηγίας. Το χρονοδιάγραμμα υλοποίησης του έργου ΑΝΝΑ εκτείνεται μέχρι το τέλος του 2015, ενώ η ενιαία ναυτιλιακή θυρίδα θα πρέπει να έχει τεθεί σε λειτουργία την 1η Ιουνίου 2015.

1.1. Υποβολή αναφορών σύμφωνα με την οδηγία 2010/65/ΕΕ

Σύμφωνα με τις απαιτήσεις της οδηγίας 2010/65/ΕΕ και του ΠΔ 125/2012, οι πλοίαρχοι των πλοίων ή οι ναυτικοί πράκτορες ή άλλα πρόσωπα ειδικά εξουσιοδοτημένα από τους πλοιοκτήτες ή τους εκμεταλλευόμενους των πλοίων, θα κοινοποιούν, πριν από τον κατάπλου/απόπλου σε/από ελληνικό λιμένα, τις πληροφορίες που απαιτούνται για τις διατυπώσεις υποβολής δηλώσεων στην ενιαία ναυτιλιακή θυρίδα. Ως διατυπώσεις υποβολής δηλώσεων ορίζονται οι πληροφορίες που αναφέρονται στο Παράρτημα του ΠΔ 125/2012, οι οποίες παρέχονται για διοικητικούς και διαδικαστικούς σκοπούς όταν πλοίο καταπλέει σε ή αποπλέει από ελληνικό λιμένα και ονομαστικά είναι οι:

1. Κοινοποίηση για πλοία κατά τον κατάπλου σε λιμένες κρατών μελών ή τον απόπλου από αυτούς (Άρθρο 4 της οδηγίας 2002/59/ΕΚ)

2. Συνοριακοί έλεγχοι προσώπων (Άρθρο 7 του Κανονισμού (ΕΚ) αριθ. 562/2006) 3. Κοινοποίηση επικινδύνων ή ρυπογόνων εμπορευμάτων που ευρίσκονται επί του

πλοίου (Άρθρο 13 της οδηγίας 2002/59/ΕΚ) 4. Κοινοποίηση αποβλήτων και καταλοίπων (Άρθρο 6 της Οδηγίας 2000/59/ΕΚ)


Έργο ΑΝΝΑ

5. Κοινοποίηση πληροφοριών σχετικών με την ασφάλεια (Άρθρο 6 του Κανονισμού (ΕΚ) αριθ. 725/2004)

6. Συνοπτική διασάφηση εισόδου (Άρθρο 36α του Κανονισμού (ΕΟΚ) αριθ. 2913/92 & Άρθρο 87 του Κανονισμού (ΕΚ) 450/2008)

7. Έντυπα FAL και διατυπώσεις που απορρέουν από διεθνείς νομικές πράξεις: Έντυπο FAL 1: Γενικό Δηλωτικό Έντυπο FAL 2: Δηλωτικό Φορτίου Έντυπο FAL 3: Δηλωτικό εφοδίων πλοίου Έντυπο FAL 4: Δηλωτικό προσωπικών ειδών πληρώματος Έντυπο FAL 5: Κατάσταση πληρώματος Έντυπο FAL 6: Κατάσταση επιβατών Έντυπο FAL 7: Δηλωτικό επικινδύνων φορτίων Ναυτιλιακό δηλωτικό υγείας

Πέραν των παραπάνω, ως διατυπώσεις υποβολής δηλώσεων θεωρούνται και οι πληροφορίες που υποβάλλονται κατά τον κατάπλου και απόπλου πλοίων σε λιμένες κρατών μελών, δυνάμει των Άρθρων 9 και 24 της οδηγίας 2009/16/ΕΚ.

Η ενιαία ναυτιλιακή θυρίδα θα συνδέει το σύστημα ανταλλαγής ναυτιλιακών πληροφοριών SafeSeaNet, το ηλεκτρονικό τελωνείο, το σύστημα Σένγκεν και το πληροφοριακό σύστημα του έργου Shipsan και θα αποτελεί τον τόπο στον οποίο όλες οι πληροφορίες θα δηλώνονται μια φορά από τους υπόχρεους και ακολούθως θα διατίθενται ηλεκτρονικά στις διάφορες αρμόδιες εθνικές αρχές και στα κράτη μέλη.

1.2. Βασικές απαιτήσεις οδηγίας 2010/65/ΕΕ

Ο κύριος στόχος της οδηγίας 2010/65/ΕΕ είναι η απλοποίηση και η εναρμόνιση των διοικητικών διαδικασιών που εφαρμόζονται στις θαλάσσιες μεταφορές, καθιερώνοντας την ηλεκτρονική ανταλλαγή πληροφοριών και εξορθολογίζοντας τις διατυπώσεις υποβολής δηλώσεων. Οι βασικές απαιτήσεις που περιγράφονται σε αυτή θα περιγραφούν στη συνέχεια. Επισημαίνεται, ότι το πληροφοριακό σύστημα που περιγράφεται στην παρούσα Διακήρυξη και θα αναπτυχθεί στο πλαίσιο αυτής, θα πρέπει να είναι πλήρως συμβατό σε όλα τα τμήματα του με αυτές τις βασικές απαιτήσεις.

1.2.1. Διαβίβαση διατυπώσεων υποβολής δηλώσεων με ηλεκτρονικό μορφότυπο

Σύμφωνα με το άρθρο 5.1 της οδηγίας, η εκπλήρωση των διατυπώσεων υποβολής δηλώσεων γίνεται αποδεκτή με ηλεκτρονικό μορφότυπο και με τη διαβίβασή τους σε εθνική ενιαία θυρίδα. Αυτό σημαίνει ότι η πληροφορία θα πρέπει να κωδικοποιείται ψηφιακά με δομημένο μορφότυπο, το οποίο θα είναι κατάλληλο για ανταλλαγή ηλεκτρονικών μηνυμάτων, επεξεργασία και αποθήκευση από ηλεκτρονικούς υπολογιστές. Για το λόγο αυτό, θα υποστηρίζονται μηνύματα XML και EDIFACT και όχι αρχεία που αποστέλλονται συνήθως ως συνημμένα σε μηνύματα ηλεκτρονικού ταχυδρομείου, όπως pdf, doc, xls και jpg. Οι πληροφορίες που θα εισάγονται στην ενιαία θυρίδα, θα αποθηκεύονται σε κατάλληλο κόμβο αποθήκευσης και στη συνέχεια θα διανέμονται στις αρμόδιες εθνικές αρχές (τελωνειακές, λιμενικές, αστυνομικές, υγειονομικές).

1.2.2. Δήλωση πληροφοριών μια φορά


Έργο ΑΝΝΑ

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

1.2.3. Διαδικασίες ανταλλαγής δεδομένων

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

Δεδομένα θα είναι δυνατό να ανταλλάσσονται και απευθείας μεταξύ εθνικών ναυτιλιακών θυρίδων με σκοπό τη διευκόλυνση της θαλάσσιας κυκλοφορίας και των εμπορικών συναλλαγών εντός της Ε.Ε., πάντα στα πλαίσια του υφιστάμενου νομικού πλαισίου.

Επιπλέον, τα δεδομένα που αφορούν τις παρακάτω διατυπώσεις υποβολής δηλώσεων, θα πρέπει να ανταλλάσσονται μέσω του ευρωπαϊκού συστήματος ανταλλαγής ναυτιλιακών πληροφοριών SafeSeaNet:

Κοινοποίηση για πλοία κατά τον κατάπλου σε λιμένες κρατών μελών ή τον απόπλου από αυτούς

Κοινοποίηση επικινδύνων ή ρυπογόνων εμπορευμάτων που ευρίσκονται επί του πλοίου

Κοινοποίηση αποβλήτων και καταλοίπων Κοινοποίηση πληροφοριών σχετικών με την ασφάλεια

Όπως καταγράφεται και στο άρθρο 3.2 της οδηγίας, τα κράτη συνεργάζονται με την Ε. Επιτροπή για την ανάπτυξη μηχανισμών εναρμόνισης και συντονισμού των διατυπώσεων υποβολής δηλώσεων εντός της Ευρωπαϊκής Ένωσης. Για το σκοπό αυτό και λόγω της πολυπλοκότητας σχεδιασμού και υλοποίησης των εθνικών ενιαίων θυρίδων των κρατών-μελών, της εμπλοκής διαφόρων εθνικών αρχών καθώς και των τεχνικών δυσχερειών για τη σχεδίαση και υλοποίησή τους, η Διεύθυνση Εφοδιαστικής, Χερσαίων και Θαλασσίων Μεταφορών της Ε. Επιτροπής (DG MOVE/D) έχει συστήσει την Ομάδα Εμπειρογνωμόνων eMS (Expert group on Maritime administrative simplification and electronic information services) για την αντιμετώπιση των τεχνικών θεμάτων της εφαρμογής της Κ.Ο. 2010/65/ΕΕ. Η ανωτέρω ομάδα υποστηρίζεται από σειρά Υποομάδων για την αντιμετώπιση θεμάτων που αφορούν τελωνειακές διατυπώσεις με τη συμμετοχή της DG TAXUD, διατυπώσεις ελέγχου συνόρων με τη συμμετοχή της DG HOME, διατυπώσεις ναυτιλιακού ενδιαφέροντος και διαχείρισης αποβλήτων πλοίων με τη συμμετοχή της DG MOVE και διατυπώσεων υγειονομικού ενδιαφέροντος πλοίων με τη συμμετοχή της DG SANCO.


Έργο ΑΝΝΑ

Επίσης, η δράση ΑΝΝΑ συνεισφέρει περαιτέρω στη συνεργασία και εναρμόνιση μεταξύ των κ-μ, μέσω της θέσπισης κοινών προτύπων και ανταλλαγής γνώσης, ενώ παράλληλα παρακολουθεί από κοντά τις εξελίξεις στην ομάδα eMS.

1.2.4. Συμβατότητα με υφιστάμενους κανόνες για την κοινοποίηση πληροφοριών πριν τον κατάπλου

Σύμφωνα με το πνεύμα της οδηγίας 2010/65/ΕΕ, δεν εισάγεται κάποια νέα υποχρέωση υποβολής αναφορών από την πλευρά των υπόχρεων, αλλά όλες οι υφιστάμενες αναφορές που απαιτούνται από διαφορετικά νομικά κείμενα θα πρέπει να αποστέλλονται ηλεκτρονικά, σύμφωνα με τις χρονικές απαιτήσεις του κάθε επιμέρους κειμένου. Για παράδειγμα, σύμφωνα με την οδηγία 2002/59/ΕΚ (ΠΔ 49/2005), αναφορά 24 ωρών προ κατάπλου υποβάλλεται από τους υπόχρεους τουλάχιστον 24 ώρες πριν από τον αναμενόμενο χρόνο κατάπλου στο λιμένα ή στο αγκυροβόλιο, ή το αργότερο, κατά το χρόνο απόπλου του πλοίου από τον προηγούμενο λιμένα, εφόσον η διάρκεια του ταξιδιού είναι μικρότερη από είκοσι τέσσερις ώρες, ή εάν ο λιμένας κατάπλου είναι άγνωστος ή μεταβλήθηκε κατά τη διάρκεια του ταξιδιού, ευθύς μόλις η πληροφορία αυτή γίνει γνωστή. Η ενιαία ναυτιλιακή θυρίδα που θα αναπτυχθεί θα πρέπει να είναι σύμφωνη με τις επιμέρους απαιτήσεις.

1.2.5. Προστασία προσωπικών, εμπιστευτικών και εμπορικών δεδομένων

Το σύστημα της ενιαίας ναυτιλιακής θυρίδας που θα αναπτυχθεί θα συμμορφώνεται πλήρως με τις εφαρμοστέες νομικές πράξεις της Ένωσης και την ισχύουσα νομοθεσία, προκειμένου να διασφαλίζεται η εμπιστευτικότητα των εμπορικών όπως και των άλλων εμπιστευτικών πληροφοριών που θα διακινούνται μέσω της ενιαίας ναυτιλιακής θυρίδας, σύμφωνα και με το άρθρο 8.1 της οδηγίας 2010/65/ΕΕ και του ΠΔ 125/2012.

Επίσης, μέσω συνεργασίας του αναδόχου με την Επιτροπή Παρακολούθησης Έργου (ΕΠΕ) και με την επισπεύδουσα Υπηρεσία, θα ληφθεί μέριμνα για τη διασφάλιση των δεδομένων προσωπικού χαρακτήρα τα οποία θα συλλέγονται από την ενιαία ναυτιλιακή θυρίδα, σύμφωνα με τις προβλέψεις του ν.2472/1997 ΦΕΚ (Α΄ 50).

1.3. Υφιστάμενη κατάσταση υποβολής αναφορών

Σήμερα, η υποβολή των αναφορών από πλευράς των υπόχρεων πραγματοποιείται με ποικίλους τρόπους. Για ορισμένους τύπους αναφορών, όπως λ.χ. για ορισμένα έγγραφα τελωνειακού ενδιαφέροντος, αυτή πραγματοποιείται ηλεκτρονικά, μέσω εξειδικευμένου πληροφοριακού συστήματος (ICIS net). Άλλες αναφορές, όπως αυτές που σχετίζονται με το σύστημα SafeSeaNet, αποστέλλονται μέσω ηλεκτρονικού ταχυδρομείου στις αρμόδιες αρχές. Επίσης, πολλές αναφορές αποστέλλονται σε έντυπη μορφή, ενώ ορισμένες απλά παραμένουν επί του πλοίου. Μετά τη λειτουργία της ενιαίας ναυτιλιακής θυρίδας, όλες οι απαιτούμενες αναφορές (διατυπώσεις υποβολής δηλώσεων) θα υποβάλλονται και θα διανέμονται πλέον ηλεκτρονικά, σε ένα μοναδικό σημείο.

1.4. Υφιστάμενα συστήματα για υποβολή αναφορών

1.4.1. ICISnet

Το ICISnet είναι το Πληροφοριακό Σύστημα των Τελωνείων και υποστηρίζει τη λειτουργία της Τελωνειακής Υπηρεσίας, με χρήση κεντροποιημένων λειτουργιών και υπηρεσιών που προσφέρονται στους συναλλασσόμενους ηλεκτρονικά.


Έργο ΑΝΝΑ

Περισσότερες πληροφορίες είναι διαθέσιμες στο https://portal.gsis.gr/portal/page/portal/ICISnet

1.4.2. SafeSeaNet

Το SafeSeaNet (SSN) είναι ένα ευρωπαϊκό σύστημα ανταλλαγής ναυτιλιακών πληροφοριών, το οποίο δημιουργήθηκε με κύριους στόχους τη βελτίωση της ασφάλειας ναυσιπλοΐας (safety), της ασφάλειας πλοίων και λιμένων (security), της προστασίας του θαλάσσιου περιβάλλοντος και της αποδοτικότητας της ναυτιλιακής κίνησης και των ναυτιλιακών μεταφορών.

Το SafeSeaNet, διασυνδέει τις ναυτιλιακές αρχές των συμμετεχόντων κρατών (κ-μ Ε.Ε., Νορβηγία & Ισλανδία), επιτρέποντάς τους να ανταλλάσσουν πληροφορίες όπως:

• εκτιμώμενες και πραγματικές ώρες κατάπλου και απόπλου των πλοίων στους λιμένες,

• λεπτομέρειες μεταφερόμενων επικίνδυνων και ρυπογόνων φορτίων,

• πληροφορίες για θαλάσσια συμβάντα και ατυχήματα,

• πληροφορίες για τον ακριβή αριθμό των επιβαινόντων και

• θέσεις των πλοίων με βάση τις αναφορές του Αυτόματου Συστήματος Αναγνώρισης (AIS).

Η ανάπτυξη, εξέλιξη και απρόσκοπτη λειτουργία του συστήματος σε ευρωπαϊκό επίπεδο έχει ανατεθεί από την Ε. Επιτροπή στον Ευρωπαϊκό Οργανισμό για την Ασφάλεια στη Θάλασσα (EMSA).

Το νομικό πλαίσιο λειτουργίας του συστήματος SafeSeaNet είναι η οδηγία 2002/59/ΕΚ για τη δημιουργία κοινοτικού συστήματος παρακολούθησης της κυκλοφορίας των πλοίων και ενημέρωσης, η οποία ενσωματώθηκε στο εθνικό δίκαιο με το ΠΔ 49/2005. Η εν λόγω οδηγία τροποποιήθηκε με τις οδηγίες 2009/17/ΕΚ και 2011/15/ΕΕ (ΠΔ 17/2011 και ΠΔ 78/2012 αντίστοιχα). Επιπλέον, απαιτήσεις για αποστολή αναφορών μέσω του SafeSeaNet έχουν τεθεί και από την οδηγία 2009/16/ΕΚ (ΠΔ 16/2011) για τον έλεγχο των πλοίων από το κράτος λιμένα.

Οι πληροφορίες που ανταλλάσσονται μεταξύ των κ-μ είναι οι ακόλουθες:

Μηνύματα Port Plus

Τα εν λόγω μηνύματα περιλαμβάνουν τις ακόλουθες αναφορές:

• 72 ωρών προ κατάπλου,

• 24 ωρών προ κατάπλου,

• ακριβούς ώρας κατάπλου και απόπλου και

• προ κατάπλου ή απόπλου για πλοία που μεταφέρουν επικίνδυνα ή ρυπογόνα εμπορεύματα (Hazmat reports)

Μηνύματα AIS

Περιλαμβάνουν πληροφορίες που αποστέλλονται αυτόματα από τα πλοία μέσω των αντίστοιχων συσκευών τους και ακολούθως λαμβάνονται μέσω της παράκτιας υποδομής AIS, προωθούνται στο σύστημα SafeSeaNet και διατίθενται προς τις αρμόδιες αρχές κάθε κ-μ.


Έργο ΑΝΝΑ

Αναφορές περιστατικών (Incident Reports, πρώην μηνύματα Alert)

Οι συγκεκριμένες αναφορές εισάγονται στο σύστημα SafeSeaNet από τις αρμόδιες αρχές των κ-μ και περιέχουν, μεταξύ άλλων, πληροφορίες αναφορικά με:

• πλοία τα οποία, σύμφωνα με το ΠΔ 49/2005 θεωρείται ότι παρουσιάζουν δυνητικό κίνδυνο για τη ναυσιπλοΐα ή ότι συνιστούν απειλή για την ασφάλεια στη θάλασσα, την ασφάλεια των προσώπων ή το περιβάλλον,

• θαλάσσια συμβάντα και ατυχήματα, όπως καθορίζονται στο ίδιο ΠΔ

• τα αποτελέσματα επιθεωρήσεων ή εξακριβώσεων σε πλοία που έγιναν είτε με πρωτοβουλία των κ-μ, είτε κατ' αίτηση άλλου κ-μ.

Οι αναφορές που αποτελούν τμήματα του μηνύματος «Port Plus» αποστέλλονται από τους υπόχρεους προς την Τοπική Αρμόδια Αρχή και την Εθνική Αρμόδια Αρχή 24/7. Ακολούθως, καταχωρούνται στην εθνική εφαρμογή SSN από προσωπικό ΛΣ-ΕΛ.ΑΚΤ.

Οι καταχωρηθείσες πληροφορίες διαβιβάζονται αυτόματα στο Ευρωπαϊκό σύστημα SSN και είναι προσβάσιμες ανά πάσα στιγμή από εξουσιοδοτημένους χρήστες των συμμετεχόντων κρατών, μέσω διαδικτυακής εφαρμογής. Στο ευρωπαϊκό σύστημα SSN είναι διαθέσιμο το σύνολο των πληροφοριών που διακινείται σε πανευρωπαϊκό επίπεδο, δηλαδή μηνύματα Port Plus, AIS και Αναφορές Περιστατικών.

Περισσότερες πληροφορίες είναι διαθέσιμες στο http://www.hcg.gr/node/6001, καθώς και στο http://emsa.europa.eu/operations/safeseanet.html.

1.4.3. SIS II

Το Σύστημα Πληροφοριών Schengen (Schengen Information System) – S.I.S. είναι ένα κοινό ηλεκτρονικό αρχείο δεδομένων, το οποίο, βάσει συγκεκριμένων άρθρων της Συνθήκης, τα κράτη μέλη τροφοδοτούν με πληροφορίες. Συγκεντρώνει δύο μεγάλες κατηγορίες πληροφοριών. Η πρώτη αφορά αναζητούμενα πρόσωπα (διωκόμενοι, εξαφανισμένοι ενήλικες και ανήλικοι κ.λπ.). Η δεύτερη αφορά αναζητούμενα οχήματα ή αντικείμενα, όπως έγγραφα ταυτότητας, άδειες κυκλοφορίας οχημάτων και πινακίδες αριθμού κυκλοφορίας που έχουν κλαπεί ή απολεσθεί.

Σε εθνικό επίπεδο την ευθύνη της εύρυθμης λειτουργίας του S.I.S. έχει το 3ο Τμήμα Τεχνικής Υποστήριξης N.S.I.S. της Διεύθυνσης Πληροφορικής του Αρχηγείου της Ελληνικής Αστυνομίας.

Οι διατάξεις σχετικά με τη δημιουργία, τη λειτουργία και τη χρήση του Συστήματος Πληροφοριών Σένγκεν δεύτερης γενιάς (SIS II) εισήχθησαν με τον τον Κανονισμό (EΚ) αριθ. 1987/2006 του Ευρωπαϊκού Κοινοβουλίου και του Συμβουλίου της 20ής Δεκεμβρίου 2006 και στην Απόφαση 2007/533/ΔΕΥ του Συμβουλίου της 12ης Ιουνίου 2007. Με απόφασή του, το αρμόδιο Συμβούλιο Υπουργών Δικαιοσύνης και Εσωτερικών Υποθέσεων της 7/8-3-2013 , όρισε την 9η Απριλίου 2013 ως ημέρα μετάπτωσης όλου του χώρου Σένγκεν από το SIS I στο SIS II.

Σύμφωνα με τις νομικές πράξεις του SIS II (άρθ. 27 Κανονισμού και άρθρο 40 Απόφασης SIS II) πρόσβαση στο Σύστημα προβλέπεται να έχουν:

Οι αστυνομικές υπηρεσίες και οι υπηρεσίες φύλαξης των συνόρων. Οι υπηρεσίες τελωνειακών ελέγχων.


Έργο ΑΝΝΑ

Οι δικαστικές αρχές αρμόδιες για την άσκηση ποινικής δίωξης στο πλαίσιο ποινικής διαδικασίας και τη διενέργεια δικαστικής ανάκρισης πριν από την απαγγελία κατηγορίας.

Οι αρμόδιες αρχές για τη χορήγηση θεωρήσεων και τίτλων διαμονής. Οι αρμόδιες αρχές για την έκδοση αδειών κυκλοφορίας οχημάτων.

Σε εθνικό επίπεδο, πρόσβαση στο SIS II – Γενικές Αναζητήσεις Σένγκεν, προβλέπεται να έχουν η Ελληνική Αστυνομία, το Λιμενικό Σώμα, τα Τελωνεία, το Υπουργείο Δικαιοσύνης Διαφάνειας & Ανθρωπίνων Δικαιωμάτων, το Υπουργείο Εξωτερικών, το Υπουργείο Εσωτερικών και το Υπουργείο Μεταφορών. Κάθε υπηρεσία επιτρέπεται να έχει πρόσβαση σε δεδομένα καταχωρήσεων που είναι συναφή με το αντικείμενο της αποστολής της.

Επί του παρόντος, πρόσβαση στο SIS έχουν η Ελληνική Αστυνομία και το Λιμενικό Σώμα, για όλες τις καταχωρήσεις, το Υπουργείο Εξωτερικών για τις καταχωρήσεις του άρθ. 24 του Κανονισμού SIS II και τα Τελωνεία για τα άρθ. 36 και 38 της Απόφασης SIS II.

Περαιτέρω πληροφορίες διατίθενται στο http://www.hellenicpolice.gr/index.php?option =ozo_content&lang=%27..%27&perform=view&id=26982&Itemid=898&lang=.

1.4.4. Shipsan

Οι θαλάσσιες μεταφορές έχουν επιπτώσεις στην υγεία του πληθυσμού της Ευρωπαϊκής Ένωσης. Για την αντιμετώπιση όλων των δυσκολιών, υλοποιήθηκαν δυο ευρωπαϊκά προγράμματα τα SHIPSAN και SHIPSAN TRAINET (2006-2011) και το Νοέμβριο 2012 ξεκίνησε ένα νέο ευρωπαϊκό πρόγραμμα κοινής δράσης για τις θαλάσσιες μεταφορές, το SHIPSAN ACT. Το Εργαστήριο Υγιεινής και Επιδημιολογίας του Πανεπιστήμιου Θεσσαλίας σε συνεργασία με την Εθνική Σχολή Δημόσιας Υγείας και το Υπουργείο Υγείας είναι ο συντονιστής της ευρωπαϊκής Kοινής Δράσης (Joint Action). Σκοπός του προγράμματος είναι η δημιουργία μιας ολοκληρωμένης και βιώσιμης στρατηγικής σε Ευρωπαϊκό επίπεδο με σκοπό τη διαφύλαξη της υγείας των επιβατών και των εργαζομένων σε πλοία (επιβατηγά, κρουαζιερόπλοια, εμπορικά) και την πρόληψη της διακρατικής μετάδοσης των λοιμωδών νοσημάτων.

Μεταξύ των στόχων του προγράμματος είναι η βιώσιμη εφαρμογή των εργαλείων του SHIPSAN για τη μετάδοση της Ναυτιλιακής Δήλωσης Υγείας, της εκτίμησης και αντιμετώπισης κινδύνων, την έκδοση πιστοποιητικών υγείας πλοίων και την επικοινωνία της πληροφορίας μέσω υπαρχόντων μηχανισμών, όπως η οδηγία 2010/65/ΕΕ.

Περισσότερες πληροφορίες για το έργο μπορούν να αναζητηθούν στο www.shipsan.eu.


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 2: Γενική Αρχιτεκτονική

2.1. Γενική περιγραφή της αρχιτεκτονικής του συστήματος

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

Σχήμα 2.1 Ροή δεδομένων και λειτουργική αρχιτεκτονική του συστήματος

Ο κάθετος άξονας αναπαριστά τη ροή των πληροφοριών από τους υπόχρεους υποβολής προς τα διασυνδεμένα πληροφοριακά συστήματα των φορέων της διοίκησης μέσω του κεντρικού κόμβου του συστήματος, ενώ ο οριζόντιος άξονας απεικονίζει τη διασύνδεση με άλλα συστήματα ναυτιλιακών θυρίδων άλλων Κ-Μ καθώς τη λειτουργική διασύνδεση με άλλους φορείς δημόσιους ή ιδιωτικούς (όπως περιφέρειες, υπηρεσίες λιμενικών αρχών, άλλες αρχές της διοίκησης, οργανισμοί λιμένων κ.α.) με μη αυτοματοποιημένες διαδικασίες EDI αλλά μέσω γραφικού περιβάλλοντος παροχής πληροφοριών αλλά και δυνατοτήτων αναζήτησης στοιχείων και δεδομένων καθώς και επικοινωνίες μέσω ηλεκτρονικού ταχυδρομείου. Η δομή του πληροφοριακού συστήματος στην κάθετη δομή του διαιρείται σε τρία τμήματα - οντότητες: το front office , mid office και back office. Στη οριζόντιο άξονα αναπαρίσταται η ροή δεδομένων και η πρόσβαση προς το πληροφοριακό σύστημα εκτός της ροής δεδομένων που ακολουθείται από τη ροή εργασιών υποβολής αναφορών και στοιχείων από τους υπόχρεους. Με βάση τη διαίρεση αυτή στους δύο άξονες δομείται και η υλοποίηση του έργου σε πέντε (05) διακριτά αλλά αλληλένδετα πιλοτικά έργα, ώστε η


Έργο ΑΝΝΑ

συνολική τους υλοποίηση να οδηγήσει στην πλήρη ανάπτυξη της ενιαίας ναυτιλιακής θυρίδας. Τα πιλοτικά έργα αυτά είναι τα εξής:

ΥΠΟΕΡΓΟ 1: ΑΝΑΠΤΥΞΗ ΤΟΥ FRONT OFFICE ΠΟΥ ΑΦΟΡΑ ΤΗΝ ΚΑΤΑΧΩΡΗΣΗ ΔΕΔΟΜΕΝΩΝ ΑΠΟ ΤΟΥΣ ΥΠΟΧΡΕΟΥΣ ΣΤΗΝ ΕΝΙΑΙΑ ΝΑΥΤΙΛΙΑΚΗ ΘΥΡΙΔΑ

ΥΠΟΕΡΓΟ 2: ΑΝΑΠΤΥΞΗ ΤΟΥ MID OFFICE – ΚΕΝΤΡΙΚΟΣ ΚΟΜΒΟΣ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ

ΥΠΟΕΡΓΟ 3: ΔΙΑΣΥΝΔΕΣΗ ΜΕ ΣΥΣΤΗΜΑΤΑ ΦΟΡΕΩΝ ΤΗΣ ΕΛΛΗΝΙΚΗΣ ΔΗΜΟΣΙΑΣ ΔΙΟΙΚΗΣΗΣ

ΥΠΟΕΡΓΟ 4: ΠΑΡΟΧΗ ΔΙΕΠΑΦΗΣ ΠΡΟΣΒΑΣΗΣ ΚΑΙ ΔΙΑΣΥΝΔΕΣΗΣ ΜΕ ΔΗΜΟΣΙΟΥΣ ΚΑΙ ΙΔΙΩΤΙΚΟΥΣ ΦΟΡΕΙΣ ΕΚΤΟΣ ΡΟΗΣ ΔΕΔΟΜΕΝΩΝ ΕΝΙΑΙΑΣ ΝΑΥΤΙΛΙΑΚΗΣ ΘΥΡΙΔΑΣ.

ΥΠΟΕΡΓΟ 5: ΔΙΑΣΥΝΔΕΣΗ ΝΑΥΤΙΛΙΑΚΩΝ ΘΥΡΙΔΩΝ ΕΛΛΑΔΑΣ - ΚΥΠΡΟΥ

Επισημαίνεται ότι το πιλοτικό έργο 5 δεν αποτελεί αντικείμενο της παρούσας Διακήρυξης.

Στο Σχήμα 2.2 αναπαρίσταται σχηματικά η διαίρεση των πιλοτικών έργων που θα υλοποιηθούν στο έργο:

Σχήμα 2.2 Απεικόνιση της διαίρεσης των πιλοτικών έργων

Η γενική αρχιτεκτονική του συστήματος αποτυπώνεται στο Σχήμα 2.3. Στη συνέχεια, παρατίθεται περιγραφή του κάθε πιλοτικού έργου.


Έργο ΑΝΝΑ

Σχήμα 2.3 Γενική Αρχιτεκτονική του Συστήματος

2.1.1. Πιλοτικό έργο 1

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

Η υλοποίηση του περιβάλλοντος αυτού θα βασίζεται σε δύο λειτουργικές διαμορφώσεις: α) η πρώτη θα αφορά την υλοποίηση ενός γραφικού περιβάλλοντος χρήστη GUI για τη διεπαφή ανθρώπου – μηχανής (Man – to – Machine) μέσα από την οποία θα γίνεται η καταχώρηση των πληροφοριών στις αντίστοιχες φόρμες και β) η δεύτερη διαμόρφωση θα αφορά την υλοποίηση διεπαφής μηχανής – μηχανής (machine to machine) που εκτός της υλοποίησης θα περιλαμβάνει επιπρόσθετα τον καθορισμό και την παροχή της σειράς δομημένων μηνυμάτων XML όπου θα περιέχονται όλες οι πληροφορίες που οι


Έργο ΑΝΝΑ

υπόχρεοι πρέπει να καταχωρήσουν βάσει του υφιστάμενου μοντέλου δεδομένων. Η ανάπτυξη μηχανισμών διασύνδεσης μέσω αρχείων XML και διαδικτυακών υπηρεσιών (web services) είναι απαραίτητη για την ανταλλαγή δεδομένων μεταξύ των εφαρμογών των υπόχρεων και της ναυτιλιακής θυρίδας και την εξασφάλιση της διαλειτουργικότητας των συστημάτων. Η ανωτέρω λειτουργία θα πρέπει να υποστηρίζεται από την ανάπτυξη ενός οδηγού υλοποίησης των μηνυμάτων καθώς και σχετικού οδηγού αναφοράς με την αναλυτική παρουσίαση της δομής των μηνυμάτων και του τρόπου ανάπτυξης τους. Οι δύο αυτές μέθοδοι καταχώρησης δεδομένων θα υποστηρίζουν πλήρως τη λειτουργία του front office αναφορικά με την καταχώρηση των δεδομένων από τους υπόχρεους.

Στο front office θα πρέπει να αναπτυχθούν οι διαδικασίες και οι μηχανισμοί πιστοποίησης και αυθεντικοποίησης των χρηστών του πληροφοριακού συστήματος τόσο σε επίπεδο ροής εργασιών και διαδικασιών όσο και σε υλοποίηση μέσω κατάλληλων διεπαφών για την αλληλεπίδραση των χρηστών με το σύστημα, ώστε να καταστούν χρήστες του συστήματος. Συγκεκριμένα, θα παρέχεται ελεγχόμενη πρόσβαση σε όλους τους χρήστες με βάση την ελάχιστη απαιτούμενη γνώση και αρμοδιότητα (αρχή των ελάχιστων προνομίων, Principle Of Least Privilege - POLP). Επιπρόσθετα, θα πρέπει να αναπτυχθούν μηχανισμοί παρακολούθησης και ελέγχου των λογαριασμών χρηστών, καταγράφοντας κάθε ενέργεια του χρήστη (auditing).

Επιπρόσθετα, θα πρέπει να σημειωθεί ότι το front office θα είναι το μοναδικό σημείο του πληροφοριακού συστήματος στο οποίο θα παρέχεται πρόσβαση στους χρήστες μέσω Διαδικτύου. Για το λόγο αυτό θα πρέπει να ληφθεί μέριμνα για την εξασφάλιση του συστήματος από διαδικτυακές επιθέσεις. Επιπλέον, θα πρέπει το τμήμα αυτό να είναι από πλευράς ασφάλειας πλήρως προστατευμένο και να δύναται να απομονωθεί λειτουργικά από το υπόλοιπο σύστημα και ειδικά από το mid-office που αποτελεί τον κεντρικό κόμβο του συστήματος αλλά και κατ’ επέκταση από το back-office που αποτελεί την υφιστάμενη πληροφοριακή υποδομή της δημόσιας διοίκησης. Για το σκοπό αυτό θα πρέπει να εφαρμοστούν τεχνικές ασφαλούς αρχιτεκτονικής των δικτύων με χρήση τριών (03) επιπέδων δικτύων μέσω ανεξάρτητων ζωνών [Demilitarized Zone (DMZ), ενδιάμεσα και εσωτερικά δίκτυα] και ταυτόχρονα ρύθμιση των δρομολογητών (routers) και των εξυπηρετητών, ώστε να υπάρχει πλήρης έλεγχος της κυκλοφορίας. Το front office θα τοποθετηθεί σε Αποστρατικοποιημένη Ζώνη (DMZ, De-Militarized Zone), έχοντας τη δυνατότητα να λειτουργήσει αυτόνομα και να επικοινωνεί με το κεντρικό σύστημα στο οποίο θα μεταφέρονται με ασφάλεια τα σχετικά δεδομένα. Επιπρόσθετα, απαιτείται η χρήση διαδικτυακού λογισμικού και συστημάτων ασφάλειας, όπως αυτά υφίστανται στον Φορέα μας, τουλάχιστον στα κομβικά σημεία των δικτύων που θα επικοινωνούν μέσω διαδικτύου με την κεντρική πλατφόρμα του συστήματος.

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

Τα δεδομένα που καταχωρούνται από τους χρήστες ή θα προέρχονται από μέσα από διεπαφές επικοινωνίας Μ2Μ θα αποθηκεύονται προσωρινά και θα προωθούνται στο mid


Έργο ΑΝΝΑ

office είτε αυτούσια είτε υπό μορφή μηνυμάτων αφού γίνουν οι έλεγχοι ποιότητας δεδομένων και επιβεβαιωθεί η ορθότητα των στοιχείων μέσα από σειρά λογικών ελέγχων ή συσχέτισης των καταχωρούμενων στοιχείων με ήδη υφιστάμενα στοιχεία των βάσεων δεδομένων του mid-office. Η δυνατότητα αποθήκευσης δεδομένων θα εξυπηρετεί και τη δυνατότητα αυτόνομης λειτουργίας του front office για τουλάχιστον 12 ώρες. Η εφαρμογή του front οffice θα αποστέλλει και τα σχετικά μηνύματα επιβεβαίωσης στους χρήστες για την ορθότητα των υποβαλλόμενων στοιχείων και την ορθή επεξεργασία των μηνυμάτων κατά της φάσης διαχείρισης τους στην ενιαία ναυτιλιακή θυρίδα.


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

α) ΚΕΝΤΡΙΚΗ ΒΑΣΗ ΔΕΔΟΜΕΝΩΝ: Το βασικότερο στοιχείο του τμήματος αυτού είναι η κεντρική βάση δεδομένων όπου αποθηκεύονται το σύνολο των διαθεσίμων πληροφοριών για τα πεδία καταχωρήσεων που αφορούν τα πλοία, όλες τις πληροφορίες δεδομένων που περιέχονται στις αναφορές καθώς και τα αρχεία των μηνυμάτων βάσει των υποβαλλόμενων αναφορών από τους υπόχρεους βάσει του μοντέλου δεδομένων καθώς και του οδηγού υλοποίησης των μηνυμάτων. Στο σημείο αυτό θα πρέπει να σημειωθεί η εφαρμογή διαδικασιών αποτροπής διαρροής πληροφοριών (data loss prevention) ώστε να καλύπτονται οποιεσδήποτε απαιτήσεις προστασίας δεδομένων προσωπικού χαρακτήρα. Επιπρόσθετα, στο τμήμα αυτό περιλαμβάνεται η εφαρμογή διαδικασιών τήρησης αντιγράφων ασφαλείας για τη βάση δεδομένων αλλά και για τα μηνύματα που διεκπεραιώνονται.

Β) ΕΦΑΡΜΟΓΕΣ ΠΑΡΑΚΟΛΟΥΘΗΣΗΣ ΛΕΙΤΟΥΡΓΙΑΣ ΠΛΗΡΟΦΟΡΙΑΚΟΥ ΣΥΣΤΗΜΑΤΟΣ: Στον κεντρικό κόμβο του συστήματος θα δημιουργηθούν και θα υποστηρίζεται η λειτουργία εφαρμογών που σκοπό θα έχουν ελέγχουν την κατάσταση λειτουργίας υλικού και λογισμικού καθώς και τα επίπεδα διαθεσιμότητας του πληροφοριακού συστήματος, των υποσυστημάτων του καθώς και των πόρων του. Ειδικότερα, οι εφαρμογές αυτές θα παρακολουθούν τη ροή των μηνυμάτων και συγκεκριμένα τη διακίνηση των δεδομένων μεταξύ των τμημάτων του πληροφοριακού συστήματος με έμφαση από το front office προς το back office, ώστε να εξασφαλίζεται η ροή των δεδομένων προς τις αρχές της διοίκησης. Οι εφαρμογές θα είναι σε θέση να καταγράφουν την κατάσταση κάθε τμήματος λογισμικού και υλικού, ώστε να ειδοποιείται ο διαχειριστής συστήματος σε περίπτωση μη ορθής διεκπεραίωσης των μηνυμάτων που μπορεί να οφείλεται είτε σε δυσλειτουργία συσκευής δικτύου ή μη ορθή ολοκλήρωση των ελέγχων ακεραιότητας των δεδομένων. Ειδικότερα, θα πρέπει να δημιουργηθεί ένα γραφικό περιβάλλον παρακολούθησης και καταγραφής λειτουργίας του πληροφοριακού συστήματος όπου: α) θα καταγράφεται και θα εμφανίζεται η κατάσταση ροής των μηνυμάτων που υποβάλλουν οι υπόχρεοι και ο βαθμός διεκπεραίωσης τους καθώς και η φάση που βρίσκονται. Σε περίπτωση μη διεκπεραίωσης θα πρέπει να εμφανίζεται ο λόγος (π.χ. αποτυχία ελέγχων ακεραιότητας) και να συντάσσεται αυτόματο μήνυμα ηλεκτρονικού ταχυδρομείου το οποίο θα αποστέλλεται μέσω του front office προς τον υπόχρεο ώστε να ειδοποιηθεί, αν το πρόβλημα οφείλεται μόνο σε εσφαλμένα στοιχεία καταχώρησης από αυτόν. Αν οφείλεται σε σφάλμα υλικού ή λογισμικού του πληροφοριακού συστήματος θα πρέπει να εμφανίζονται αντίστοιχα


Έργο ΑΝΝΑ

προειδοποιητικά μηνύματα στο διαχειριστή της εφαρμογής. β) θα καταγράφεται και θα εμφανίζεται η κατάσταση λειτουργίας και διαθεσιμότητας όλων των φυσικών και ιδεατών μηχανών του πληροφοριακού συστήματος, του δικτυακού εξοπλισμού για τα front, mid και back office. Ειδικότερα, θα πρέπει να παρακολουθείται και να εμφανίζεται στο περιβάλλον διαχείρισης η διαθεσιμότητα πόρων, το ποσοστό χρησιμοποίησής τους, η απόδοσή τους, η κατάσταση ή απαίτηση συντήρησης κάθε τμήματος υλικού του συστήματος.

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

Γ) ΔΙΑΜΕΣΟΛΑΒΗΤΗΣ ΜΗΝΥΜΑΤΩΝ (MESSAGE BROKER): Μία εκ των κυρίων απαιτήσεων της οδηγίας 2010/65 είναι η διασύνδεση των πληροφοριακών συστημάτων των φορέων της Διοίκησης με σκοπό την ηλεκτρονική διακίνηση των υποβαλλόμενων αναφορών από τους υπόχρεους. Η υλοποίηση του διαμεσολαβητή μηνυμάτων αποτελεί βασικό στοιχείο της αρχιτεκτονικής του πληροφοριακού συστήματος της ναυτιλιακής θυρίδας, ώστε να εξασφαλιστεί η διαλειτουργικότητα μεταξύ εφαρμογών που ακολουθούν διαφορετικά μοντέλα δεδομένων. Οι βασικές λειτουργίες του διαμεσολαβητή μηνυμάτων είναι να αντλεί τις τιμές των δεδομένων από τη βάση και να συνθέτει νέα μηνύματα XML ή EDIFACT τα οποία θα αποστέλλονται προς τα συστήματα των άλλων φορέων. Τα μηνύματα αυτά που συντίθενται θα πρέπει να ακλουθούν το μοντέλο δεδομένων του παραλήπτη και να είναι συμβατά με το σύστημα του. Ο διαμεσολαβητής μηνυμάτων θα πρέπει να διαθέτει επιπρόσθετα και ένα γραφικό φιλικό περιβάλλον διεπαφής προς το διαχειριστή μέσα από το οποίο θα παρέχεται η δυνατότητα ενδεχομένης τροποποίησης των σχημάτων XML ή ακόμα και προθήκης δημιουργίας και νέων μηνυμάτων ή τροποποίησης των ρυθμίσεων αποστολής μηνυμάτων ή και την προσθήκη νέων παραληπτών με αντίστοιχη σύνθεση νέων μηνυμάτων κ.α.


Το τρίτο πιλοτικό έργο αφορά τη διασύνδεση της ενιαίας ναυτιλιακής θυρίδας και συγκεκριμένα της πληροφοριακής υποδομής του Λ.Σ.-ΕΛ.ΑΚΤ με τα κεντρικά συστήματα των άλλων φορέων της ελληνικής διοίκησης και συγκεκριμένα:

το ICISnet των τελωνειακών υπηρεσιών, το SiS του ΥΠτΠ, του πληροφοριακού συστήματος του έργου SHIPSAN για τη διακίνηση του

δηλωτικού υγείας αλλά και συγκεκριμένων υγειονομικών πληροφοριών, την κεντρική υποδομή του SafeSeaNet της EMSA στην οποία θα πρέπει να

αποστέλλονται τα μηνύματα που προβλέπονται από τις αντίστοιχες κοινοτικές οδηγίες κλπ.

Το έργο αυτό αφορά την υλοποίηση του back οffice της ενιαίας ναυτιλιακής θυρίδας.

Για τις ανάγκες του έργου θα χρησιμοποιηθούν οι δικτυακές υποδομές του ΣΥΖΕΥΞΙΣ. Στο πιλοτικό έργο αυτό θα πρέπει να αναπτυχθούν οι σχετικές διεπαφές ώστε να γίνεται προώθηση των αντίστοιχων μηνυμάτων σε άλλους Φορείς για την επίτευξη της απαιτούμενης διασύνδεσης. Επιπρόσθετα, σε συνεργασία με τα άλλα Υπουργεία ο


Έργο ΑΝΝΑ

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


Το τέταρτο πιλοτικό έργο αφορά την ανάπτυξη ενός web γραφικού περιβάλλοντος διεπαφής και εργασίας για την προβολή των δεδομένων και εξασφάλιση της πρόσβαση προς το πληροφοριακό σύστημα σε χρήστες εκτός της ροής δεδομένων που ακολουθείται από τη ροή εργασιών υποβολής αναφορών και στοιχείων από τους υπόχρεους. Ειδικότερα, το γραφικό περιβάλλον διεπαφής που θα αναπτυχθεί θα πρέπει να είναι πλήρως παραμετροποιήσιμο από το διαχειριστή και θα δύναται να διαμορφώνεται από αυτόν με βάση το προφίλ χρηστών και τα δικαιώματα τους. Ειδικότερα, ο χρήστης της εξωτερικής διεπαφής θα έχει αυξημένες δυνατότητες αναζήτησης και θα πρέπει να μπορεί να λαμβάνει τις πληροφορίες που χρειάζεται από τα υποβληθέντα δεδομένα. Για παράδειγμα: οι Περιφερειακές υγειονομικές υπηρεσίες θα πρέπει να είναι σε θέση να εισέλθουν στο σύστημα και να εξάγουν πληροφορίες που αφορούν στοιχεία του δηλωτικού υγείας. Η διεπαφή εκτός από την προβολή των στοιχείων θα πρέπει να δίνει και τη δυνατότητα εξαγωγής τους σε διάφορες μορφές όπως: pdf, xls,csv και xml. Ο χρήστης θα δύναται να εξάγει τα στοιχεία είτε σε μορφή αρχείου είτε εκτυπωμένα από την εφαρμογή καθώς και να παρέχεται η δυνατότητα αποστολής τους με ηλεκτρονικό ταχυδρομείο. Ο εξωτερικός χρήστης θα δύναται να επιλέξει τη μορφή εμφάνισης των πληροφοριών και να εξάγει ακόμα και τα μηνύματα και τις υποβληθείσες αναφορές, με την προϋπόθεση ότι διαθέτει τα αντίστοιχα δικαιώματα. Δεν πρέπει να υφίσταται περιορισμός δικαιωμάτων, αδειών χρήσης η οποιασδήποτε άλλης μορφής σε κανένα τμήμα του πιλοτικού έργου όπως άλλωστε και σε κάθε τμήμα του έργου συνολικά. Το web interface και το GUI θα πρέπει να δύναται να τροποποιηθούν από τις υπηρεσίες ΛΣ-ΕΛ.ΑΚΤ μετά την παράδοση του έργου και το περάς του χρόνου των υποχρεώσεων συντήρησης – τεχνικής υποστήριξης του Αναδόχου. Μέσα από το τέταρτο πιλοτικό έργο ο φορέας θα δίνεται να παρέχει πρόσβαση στα δεδομένα της ενιαίας ναυτιλιακής θυρίδας και σε φορείς του δημοσίου ή φορείς εκμετάλλευσης λιμένων που δε διαθέτουν πληροφορίες ανταλλαγής δεδομένων Μ2Μ. Για αυτούς τους χρήστες θα ακολουθείται διαδικασία πιστοποίησης ανάλογη με αυτή που θα ακολουθείται για τους εξωτερικούς χρήστες.

2.2. Ασφάλεια (security) του συστήματος

Α) Το σύνολο του εξοπλισμού λογισμικού και υλισμικού που θα χρησιμοποιείται θα πρέπει να λειτουργεί σε διαμόρφωση (configuration) μέγιστης ασφάλειας. Βασικό στοιχείο αποτελεί η ασφαλής διαμόρφωση όλων των δικτυακών συσκευών [δρομολογητές (routers) και μεταγωγείς (switches)] και περιοδική αναθεώρηση αυτών των διαμορφώσεων

Β) Κατά την εκπόνηση του έργου θα πρέπει να πραγματοποιηθεί πλήρης μελέτη εκτίμησης τρωτότητας του συστήματος (Vulnerability Assessment), ώστε να περιοριστούν


Έργο ΑΝΝΑ

όσο το δυνατόν περισσότερο τρωτά σημεία. Παράλληλα, θα πρέπει να εκτελεστούν έλεγχοι διείσδυσης (penetration testing) του συστήματος αλλά και έλεγχος ασφάλειας (security audit) από τον Ανάδοχο και να παρασχεθούν τα σχετικά πιστοποιητικά στο Φορέα μας. Επιπρόσθετα, οι ανωτέρω διαδικασίες καθ’ όλο το διάστημα της παροχής υπηρεσιών εγγύησης και υπηρεσιών συντήρησης – υποστήριξης θα εκτελούνται τακτικοί (προγραμματισμένοι) ή έκτακτοι έλεγχοι ασφαλείας (security audits), εκτιμήσεων τρωτοτήτων (vulnerability assessments) και ελέγχων διείσδυσης (penetration testing) του συστήματος βάσει της μελέτης εφαρμογής και του σχεδίου ασφάλειας πληροφοριακού συστήματος.

Γ) επικαιροποίηση της μελέτης εκτίμησης τρωτότητας κατά τη διάρκεια των δοκιμών του έργου και πριν την παράδοση του συνόλου του πληροφοριακού συστήματος με πλήρεις επιχειρησιακές δυνατότητες.

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

2.3. Βασικές Αρχές για την ανάπτυξη του συστήματος

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

Βασική Αρχή 1: Επεξεργάζονται μόνο οι πληροφορίες που σχετίζονται με την οδηγία 2010/65

Περιγραφή: Η Ενιαία Ναυτιλιακή Θυρίδα θα υποστηρίζει μόνο δεδομένα που περιλαμβάνονται στις διατυπώσεις υποβολής δηλώσεων της Οδηγίας 2010/65/EU. Πρόσθετα στοιχεία θα υποστηριχτούν μόνο αν υπάρξει μία ξεκάθαρη και εγκεκριμένη ανάγκη για την ενσωμάτωσή τους στην Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 2: Πεδίο εφαρμογής των διατυπώσεων υποβολής για τα τελωνεία

Περιγραφή: Υπάρχουν πολλαπλές διατυπώσεις υποβολής δηλώσεων για τα τελωνεία. Δεν καλύπτονται όλες οι διατυπώσεις από την οδηγία 2010/65. Οι ακόλουθες διατυπώσεις υποβολής δηλώσεων είναι μέρος της Ενιαίας Ναυτικής Θυρίδας:

1)Συνοπτική διασάφηση εισόδου

2) Συνοπτική διασάφηση για σκοπούς προσωρινής εναπόθεσης

3) Δήλωση των καταστημάτων του πλοίου κατά την άφιξή του.

4) Αναφορά αναμενόμενης άφιξης πλοίου

5) Αναφορά αναμενόμενης αναχώρησης πλοίου

6) Δήλωση των συμπτωμάτων του πληρώματος

Οι ακόλουθες διατυπώσεις υποβολής δηλώσεων είναι εκτός του πεδίου εφαρμογής της Ενιαίας Ναυτιλιακής Θυρίδας:


Έργο ΑΝΝΑ

7) Συνοπτική διασάφηση εξόδου

8) Δήλωση φορτίου στην αναχώρηση

9) Provisions of ship’s stores during visit

10) Δήλωση για την εισαγωγή, μεταφορά και εξαγωγή

Βασική Αρχή 3: Οι πληροφορίες κοινοποιούνται από τους υπόχρεους

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

Βασική Αρχή 4: Μία αναφορά, πολλαπλή χρήση των δεδομένων

Περιγραφή: Οι πληροφορίες για τις (πολλαπλές) Δημόσιες Αρχές είναι απαραίτητο να υποβάλλονται στην Ενιαία Ναυτιλιακή Θυρίδα από τους «Υπόχρεους» και εν συνεχεία η Ενιαία Ναυτιλιακή Θυρίδα θα μεταβιβάζει τις πληροφορίες στις Δημόσιες Αρχές που τους έχει επιτραπεί να λαμβάνουν αυτές τις πληροφορίες. Σε περίπτωση που οι πληροφορίες μεταβληθούν, οι «Υπόχρεοι» χρειάζεται να υποβάλλουν τις τροποποιήσεις στην Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 5: Δεδομένα που οι Δημόσιες Αρχές έχουν ήδη, δεν θα ζητούνται εφόσον αυτό είναι εφικτό

Περιγραφή: Η οδηγία 2010/65 βασίζεται στο «Μία παράδοση, πολλαπλές χρήσεις». Έχοντας αυτό σαν αρχή, η Ενιαία Ναυτιλιακή Θυρίδα εάν είναι δυνατόν, στο πλαίσιο των νομικών περιορισμών, δεν θα αιτείται τα στοιχεία τα οποία οι Δημόσιες Αρχές ήδη διαθέτουν, παρόλο που η παράδοση αυτών των δεδομένων αναφέρεται στις διατυπώσεις υποβολής δηλώσεων.

Βασική Αρχή 6: Χρήση των τύπων δηλώσεων

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

Βασική Αρχή 7: Χρήση μοναδικών αναγνωριστικών για τα δεδομένα

Περιγραφή: Τα δεδομένα που υποβάλλονται πρέπει να ομαδοποιούνται. Η ομαδοποίηση γίνεται με τη χρήση αναγνωριστικών για την Αναφορά πλοίου {Vessel Call}. Αναφορά πλοίου (visit_id): Η Ενιαία Ναυτιλιακή Θυρίδα συσχετίζει όλα τα υποβληθέντα δεδομένα στις αναφορές πλοίων καθώς επίσης και δεδομένα που σχετίζονται με την άφιξη και αναχώρηση πλοίου. Για όλους τους τύπους δηλώσεων ισχύει ότι τα δεδομένα σχετίζονται με ένα μοναδικό αναγνωριστικό στην Αναφορά Πλοίου το οποίο εκδίδεται από το σύστημα.

Βασική Αρχή 8: Οι πληροφορίες υποβάλλονται στην Ενιαία Ναυτιλιακή Θυρίδα μόνο μέσω μηνυμάτων

Περιγραφή: Οι υπόχρεοι μπορούν να υποβάλλουν πληροφορίες είτε αποστέλλοντας απευθείας μηνύματα στην Ενιαία Ναυτιλιακή Θυρίδα, είτε καταχωρώντας τα χειροκίνητα


Έργο ΑΝΝΑ

σε GUI (Γραφικό Περιβάλλον) το οποίο θα πρέπει να στέλνει τις πληροφορίες στο ίδιο μήνυμα, όπως η διεπαφή Μηχανής με Μηχανή (Μ2Μ).

Βασική Αρχή 9: Ένα μήνυμα για όλες τις διατυπώσεις υποβολής δηλώσεων

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

Βασική Αρχή 10: Χρήση της δομής μηνύματος του μοντέλου δεδομένων WCO

Περιγραφή: Τα μηνύματα της Ενιαίας Ναυτιλιακής Θυρίδας θα βασίζονται σε μία γενική δομή μηνύματος του μοντέλου δεδομένων WXO. Το μήνυμα XML του μοντέλου δεδομένων WXO (π.χ. GOVXML) θα είναι το μήνυμα για ανταλλαγή δεδομένων μεταξύ της Ενιαίας Ναυτιλιακής Θυρίδας και των άλλων μερών. Το ISO 28005 είναι επίσης υπό διερεύνηση και θα μπορούσε επίσης να συμπεριληφθεί ως πρότυπο για ανταλλαγή δεδομένων.

Βασική Αρχή 11: Υποστήριξη μηνυμάτων XML και EDIFACT

Περιγραφή: Η Ενιαία Ναυτιλιακή Θυρίδα θα μπορεί να λάβει και να επεξεργαστεί μηνύματα EDIFACT και XML. Τα μηνύματα θα πρέπει να πληρούν τους ορισμούς των μηνυμάτων της Ενιαίας Ναυτιλιακή Θυρίδας.

Βασική Αρχή 12: Καμία υποστήριξη των παρόντων μηνυμάτων.

Περιγραφή: Η Ενιαία Ναυτιλιακή Θυρίδα ΔΕΝ θα υποστηρίξει την λήψη και επεξεργασία των μηνυμάτων που χρησιμοποιούνται σήμερα για τις διατυπώσεις υποβολής δηλώσεων.

Βασική Αρχή 13: Απαντητικά μηνύματα από την Ενιαία Ναυτιλιακή Θυρίδα

Περιγραφή: Για κάθε μήνυμα που λαμβάνεται, η Ενιαία Ναυτιλιακή Θυρίδα θα επιστρέφει επιβεβαίωση λήψης και μία απάντηση που περιλαμβάνει αποδοχή ή απόρριψη. Η αποδοχή σημαίνει ότι το μήνυμα μπορεί να επεξεργαστεί από την Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 14: Πιθανοί δίαυλοι για τις διατυπώσεις υποβολής δηλώσεων της ναυτιλιακής βιομηχανίας

Περιγραφή: Όλες οι διατυπώσεις υποβολής υποστηρίζονται από την Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 15: Συνδεδεμένα συστήματα Δημοσίων Αρχών

Περιγραφή: Οι υποβληθέντες πληροφορίες διαβιβάζονται σε ένα περιορισμένο σύνολο Δημοσίων Αρχών (Αρμόδιες Αρχές). Το σύνολο αυτό των Δημοσίων Αρχών βασίζεται στις διατυπώσεις υποβολής δηλώσεων της οδηγίας 2010/65. Μόνο τα συστήματα αυτών των Αρμοδίων Αρχών συνδέονται στην Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 16: Άλλα συνδεδεμένα συστήματα

Περιγραφή: Στο μέλλον η Ενιαία Ναυτιλιακή Θυρίδα να συνδεθεί και με άλλα συστήματα. Ο καθολικός σχεδιασμός της Ενιαίας Ναυτιλιακής Θυρίδας θα λάβει υπόψη ότι


Έργο ΑΝΝΑ

οι Ενιαίες Ναυτιλιακές Θυρίδες άλλων Κ-Μ θα δύναται να συνδεθούν απευθείας στην Ενιαία Ναυτιλιακή Θυρίδα.

Βασική Αρχή 17: Ένας «Υπόχρεος» ανά μήνυμα

Περιγραφή: Κάθε μήνυμα περιλαμβάνει έναν ή περισσότερους Τύπους Δήλωσης. Το μήνυμα B2MSW είναι πάντα συσχετισμένο με έναν μόνο «Υπόχρεο». Αυτό καθορίζεται στο κύριο μέρος του μηνύματος.

Βασική Αρχή 18: Κανόνες για Τύπους Αναφορών

Περιγραφή: Τα μηνύματα θα πρέπει να πληρούν τους παρακάτω κανόνες:Κάθε μήνυμα B2MSW θα πρέπει πάντα να περιλαμβάνει ακριβώς μία κεφαλίδα τύπου δήλωσης (DT MAI) και τουλάχιστον έναν άλλο Τύπο Δήλωσης.Όλοι οι Τύποι Δήλωσης μπορεί να υποβληθούν είτε ως ένας τύπος ανά μήνυμα ή με οποιοδήποτε συνδυασμό τύπων σε ένα μήνυμα. Προκειμένου να συσχετιστούν ποικίλες δηλώσεις το DT MAI θα πρέπει πάντα να περιλαμβάνει τουλάχιστον τον λιμένα κατάπλου, το αναγνωριστικό του πλοίου, την ημερομηνία άφιξης και (με εξαίρεση το DT ENS), το CALL_ID.

Βασική Αρχή 19: Πληροφορίες φορτίου στου Τύπους Δηλώσεων

Περιγραφή: Σε όλους τους Τύπους Δηλώσεων που σχετίζονται με το φορτίο (ENS, SDT, HZA, HZD) μπορούν να υποβληθούν ακριβώς οι ίδιες λεπτομέρειες φορτίου. Διαδικαστικοί κανόνες στα στοιχεία (π.χ. υποχρεωτικές, προαιρετικές και με υπό όρους) είναι (κυρίως) διαφορετικές ανά Τύπο Δήλωσης.

Βασική Αρχή 20: Δηλώσεις φορτίων

Περιγραφή: Οι ακόλουθοι κανόνες εφαρμόζονται για δηλώσεις σχετικές με το φορτίο (ENS, SDT, HZA και HZD)

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

2) Το φορτίο αναγνωρίζεται μοναδικά σε αποστολές.

Α) Οι αποστολές αναγνωρίζονται μέσα στον Τύπο Δήλωσης

Β) Οι παρτίδες αναγνωρίζονται μέσα στις αποστολές

Γ) Οι υποβληθείσες αποστολές/παρτίδες εντός διαφορετικών τύπων δήλωσης θεωρούνται διαφορετικά είδη αποστολών/παρτίδων ανεξάρτητα από το αν το φορτίο φαίνεται να είναι «πανομοιότυπο»

3) Οι αποστολές θα πρέπει να αναφέρονται ρητά σύμφωνα με τον σχετικό Τύπο Δήλωσης (ENS, SDT, HZA, HZD) ακόμα και αν οι τύποι δηλώσεων υποβάλλονται στο ίδιο μήνυμα (B2MSW)

4) Η Ενιαία Ναυτιλιακή Θυρίδα επιτρέπει οι υποβληθείσες αποστολές από ποικίλους Τύπους Δήλωσης να είναι διαφορετικές.

Βασική Αρχή 21: Υποχρεωτικοί συνδυασμοί Τύπων Δήλωσης

Περιγραφή: Οι ακόλουθοι τύποι δηλώσεων πρέπει να υποβάλλονται μέσα στο ίδιο μήνυμα:


Έργο ΑΝΝΑ

1) Εάν απαιτείται η υποβολή τους, οι πληροφορίες ασφάλειας πρέπει πάντα να υποβάλλονται ταυτόχρονα με τις πληροφορίες προ κατάπλου. Οι πληροφορίες προ κατάπλου μπορούν να υποβληθούν χωρίς τις πληροφορίες ασφάλειας.

2) Εάν απαιτείται η υποβολή τους, οι, πληροφορίες της Ναυτιλιακής Δήλωσης Υγείας πρέπει πάντα να υποβάλλονται ταυτόχρονα με πληροφορίες για τον αριθμό επιβαινόντων. Πληροφορίες για τον αριθμό επιβαινόντων δύναται να υποβληθούν χωρίς την Ναυτική Δήλωση Υγείας.

Βασική Αρχή 22: Μηχανισμοί ενημέρωσης για τα μηνύματα B2MSW

Περιγραφή: Οι ακόλουθες αρχές εφαρμόζονται για την υποβολή πληροφοριών στην Ενιαία Ναυτιλιακή Θυρίδα. Οι δηλούντες πρέπει:

Είτε να επαναλαμβάνουν όλους τους Τύπους Δήλωσης στα μηνύματά τους ή να συμπεριλάβουν μόνο τους νέους ή τροποποιημένους Τύπους Δήλωσης.

Μη συμπεριλαμβανόμενοι Τύποι Δήλωσης θεωρείται ότι δεν αλλάζουν.

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

Στους Τύπους Δηλώσεων φορτίου (π.χ. DT ENS, DT SDT, DT HZA DT HZD) εφαρμόζεται ο μηχανισμός Τροποποίησης, πέραν του μηχανισμού Αντικατάστασης που ισχύει για το σύνολο του Τύπου Δήλωσης.

Στους λοιπούς Τύπους Δηλώσεων εφαρμόζεται ο μηχανισμός Αντικατάστασης.

Βασική Αρχή 23: Μηχανισμός ακύρωσης και ανάκλησης πληροφοριών

Περιγραφή: 1) Ακύρωση της αναφοράς πλοίου: Η ακύρωση γίνεται μέσω του Τύπου Δήλωσης COA. Το αποτέλεσμα της ακύρωσης αναφοράς είναι ότι το σύνολο των υποβληθέντων Τύπων Δηλώσεων μαζί με τα τις υποκείμενες πληροφορίες χαρακτηρίζονται ως διαγραμμένα και λογίζονται ως μη υποβληθέντα. Αυτό γίνεται από τον “Υπόχρεο” που υπέβαλλε τον Τύπο Δήλωσης NOA

2) Ανάκληση των υποβληθέντων Τύπων Δεδομένων: Οι υποβληθέντες Τύποι Δεδομένων δεν είναι δυνατό να ακυρωθούν μεμονωμένα. Οι ακόλουθες πρακτικές εφαρμόζονται: Ενημερώνεται ένας Τύπος Δεδομένων στέλνοντας ένα “κενό” μήνυμα B2MSW (π.χ. Πληροφορίες συγκεκριμένου Τύπου Δεδομένων αφαιρούνται σε μία ενημέρωση). Αυτό είναι δυνατό για τους ακόλουθους Τύπους Δηλώσεων: (DT SEC, DT WAS, DT STO, DT PAX, DT MDH, DT ENS, DT SDT, DT HZA, DT HZD)

3) Ανάκληση πληροφοριών που σχετίζονται με το φορτίο όταν χρησιμοποιείται ο μηχανισμός Τροποποίησης: Ο τελευταίος χρησιμοποιεί την κατάσταση διαγραφής ανά αποστολή ή εξοπλισμό μεταφοράς.

Βασική Αρχή 24: Τα μηνύματα επεξεργάζονται με τη σωστή ακολουθία

Περιγραφή: Κάθε μήνυμα ενημέρωσης έχει μια αναφορά σε προηγούμενο μήνυμα του ίδιου “Υπόχρεου” που εστάλη από το ίδιο υπολογιστικό σύστημα για την ίδια αναφορά


Έργο ΑΝΝΑ

πλοίου. Παρόλα αυτά, μηνύματα από την ίδια αναφορά πλοίου μπορεί να ληφθούν με διαφορετική σειρά από αυτή που έστειλαν οι “Υπόχρεοι” επειδή

1.Τα μηνύματα χάθηκαν

2.Τα μηνύματα από τον ίδιο “Υπόχρεο” που εστάλησαν από το ίδιο υπολογιστικό σύστημα μπορεί να παρελήφθησαν με διαφορετική σειρά από αυτή που αποστάλθηκαν

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

Βασική Αρχή 25: Σκοπός επαλήθευσης επεξεργασίας μηνυμάτων

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

Βασική Αρχή 26: Κανένας έλεγχος στον χρόνο υποβολής των δηλώσεων

Περιγραφή: Η Ενιαία Ναυτιλιακή Θυρίδα ΔΕΝ θα ελέγχει εάν οι δηλώσεις υποβλήθηκαν εγκαίρως. Το “εγκαίρως” μπορεί να ερμηνευθεί με δύο τρόπους:

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

2) Η νομοθεσία απαιτεί ότι ορισμένοι Τύποι Δηλώσεων πρέπει να υποβληθούν πριν από κάποια κατάσταση. (π.χ. ο Τύπος Δήλωσης PAX πρέπει να υποβληθεί πριν τον πραγματικό χρόνο κατάπλου του πλοίου στον λιμένα, δηλαδή πριν τον Τύπο Δήλωσης ATA)

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

Βασική Αρχή 27:Κανένας έλεγχος στην πληρότητα των δηλώσεων για πλοίο.

Περιγραφή: Η Ενιαία Ναυτιλιακή Θυρίδα ΔΕΝ θα ελέγχει:

1) Εάν έχουν υποβληθεί όλες οι διατυπώσεις υποβολής δηλώσεων για συγκεκριμένο πλοίο.

2) Εάν οι διατυπώσεις υποβολής δηλώσεων έχουν υποβληθεί πιθανώς λανθασμένα από ένα πλοίο.

Όλες οι υποβληθέντες πληροφορίες επεξεργάζονται και διαβιβάζονται στις αρμόδιες αρχές. Άπτεται στις αρμόδιες αρχές να προβούν σε κυρώσεις εάν τα πλοία δεν υπέβαλλαν ορθά τις αναφορές.

Βασική Αρχή 28: Η επεξεργασία μηνύματος είναι αποσυνδεδεμένη από την παροχή μηνυμάτων.


Έργο ΑΝΝΑ

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

Βασική Αρχή 29: Δεν θα αποθηκεύονται ιστορικά δεδομένα για τα στοιχεία.

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

Βασική Αρχή 30: Χρήση των δεδομένων αναφοράς στη διαδικασία επεξεργασίας μηνυμάτων.

Περιγραφή: Δεδομένα αναφοράς θα χρησιμοποιούνται για να συμπληρώσουν τα ληφθέντα μηνύματα (B2MSW). Εάν τα δεδομένα αναφοράς αποστέλλονται με το μήνυμα, τότε είναι ανώτερα των δεδομένων αναφοράς στη βάση δεδομένων της Ενιαίας Ναυτιλιακής Θυρίδας. (π.χ. Εάν η ληφθείσα “σημαία” του πλοίου είναι διαφορετική από αυτή της βάσης συσχέτισης, η ληφθείσα “σημαία” θα θωρηθεί ως αληθής.)

Βασική Αρχή 31: Ημερομηνία/Ώρα

Περιγραφή: Οι ακόλουθες αρχές εφαρμόζονται για ημερομηνίες/ώρες:

1) Για ημερομηνίες/ώρες χρησιμοποιείται το πρότυπο ISO 8601 με την εκτεταμένη διαμόρφωσή του (Δηλαδή ΕΕΕΕ-ΜΜ-ΗΗ ΩΩ:ΛΛ:ΔΔ) για όλα τα μηνύματα.

2) οι “Υπόχρεοι” έχουν τις ακόλουθες επιλογές για να κοινοποιούν ημερομηνίες/ώρες στα μηνύματα B2MSW:

Α) Σε UTC, με ένδειξη ζώνης ώρας Ζ

Β) Σε τοπική ημερομηνία/ώρα με την ένδειξη διαφοράς ώρας (Δηλαδή ±ΩΩ:ΛΛ)

3) Οι ημερομηνίες/ώρες διαβιβάζονται στα άλλα ΚΜ σε UTC με την ένδειξη ζώνης ώρας.

2.4. Γενικά σημεία για την ανάπτυξη του συστήματος

2.4.1. Γενικές Αρχές ανάπτυξης του συστήματος

Οι γενικές αρχές που θα διέπουν το σύνολο των εφαρμογών – υποσυστημάτων που θα αναπτυχθούν σε λειτουργικό και τεχνολογικό επίπεδο είναι:

1. Συστήματα «ανοικτής» αρχιτεκτονικής (open architecture), δηλαδή είναι υποχρεωτική η χρήση ανοικτών προτύπων που θα διασφαλίζουν ανεξαρτησία από συγκεκριμένο προμηθευτή και:

ομαλή συνεργασία και λειτουργία μεταξύ των επιμέρους εφαρμογών και υποσυστημάτων του πληροφοριακού συστήματος,

δικτυακή συνεργασία μεταξύ εφαρμογών ή/και συστημάτων τα οποία βρίσκονται σε διαφορετικά υπολογιστικά συστήματα,

επεκτασιμότητα των συστημάτων και εφαρμογών,

εύκολη επέμβαση στη λειτουργικότητα των εφαρμογών (συντηρησιμότητα – maintainability).


Έργο ΑΝΝΑ

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

3. Αρχιτεκτονική N-tier, για την αποδοτική εκμετάλλευση του δικτύου και την ευκολία στην επεκτασιμότητα.

4. Λειτουργία των επιμέρους εφαρμογών, υποσυστημάτων και λύσεων που θα αποτελέσουν διακριτά τμήματα της λύσης που θα προσφερθεί σε web-based περιβάλλον, το οποίο θα αποτελέσει το βασικό «χώρο εργασίας» για τους «διαχειριστές» και τους εξουσιοδοτημένους χρήστες των εφαρμογών με στόχο την:

• επίτευξη της μεγαλύτερης δυνατής ομοιομορφίας στις διεπαφές μεταξύ των διαφόρων υποσυστημάτων και στον τρόπο εργασίας τους,

• επιλογή κοινών και φιλικών τρόπων παρουσίασης, όσον αφορά στις διεπαφές των χρηστών με τις εφαρμογές.

5. Εξασφάλιση πλήρους λειτουργικότητας μέσω του εσωτερικού δικτύου (intranet) και του Διαδικτύου (Internet) όπου αυτό απαιτείται.

6. Χρήση συστημάτων διαχείρισης σχεσιακών βάσεων δεδομένων (RDBMS). Διευκρινίζεται ότι με τις άδειες χρήσης του λογισμικού διαχείρισης σχεσιακών βάσεων δεδομένων (RDBMS) θα πρέπει να διασφαλίζονται:

• άδειες χρήσης του λογισμικού διαχείρισης της ΒΔ

• ανοικτό περιβάλλον ανάπτυξης εφαρμογών,

• ανοικτά τεκμηριωμένα και δημοσίως διαθέσιμα συστήματα διεπαφής με προγράμματα τρίτων,

• ανοικτά πρωτόκολλα επικοινωνίας,

• ανοικτό περιβάλλον ως προς τη μεταφορά και ανταλλαγή δεδομένων με άλλα συστήματα.

• δυνατότητες επέκτασης στο υπάρχον σχήμα βάσης

7. Τα εργαλεία ανάπτυξης, συντήρησης και διαχείρισης των εφαρμογών που θα χρησιμοποιηθούν θα πρέπει είναι συμβατά με το σύνολο του λογισμικού υποδομής που θα προσφερθεί από τον Ανάδοχο (Web, application και database servers), τα οποία θα παραδοθούν στο Φορέα μας.

8. Ενσωμάτωση στα υποσυστήματα άμεσης υποστήριξης βοήθειας (online help) και οδηγιών προς τους χρήστες ανά διαδικασία ή και οθόνη.

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

10. Διασφάλιση της πληρότητας, ακεραιότητας, εμπιστευτικότητας και ασφάλειας των δεδομένων των εφαρμογών.


Έργο ΑΝΝΑ

11. Τεκμηρίωση του συστήματος μέσω της αναλυτικής περιγραφής της βάσης δεδομένων και των εφαρμογών. Σύνταξη τεχνικών εγχειριδίων του συστήματος και των εργαλείων διαχείρισης (system manuals), καθώς και λεπτομερή εγχειρίδια λειτουργίας του συστήματος (operation manuals) και υποστήριξης των χρηστών (user manuals).

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

13. Αξιοποίηση της τεχνολογίας server consolidation και virtualization και πιο συγκεκριμένα λειτουργία των συστημάτων που θα αναπτυχθούν σε περιβάλλον εικονικών μηχανών (virtual machines)

14. Να παραδοθεί εκτός από το παραγωγικό και επιπλέον UAT, staging & development περιβάλλον

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

16. Όλη η επικοινωνία με τον έξω κόσμο θα γίνεται μέσω ασφαλούς σύνδεσης SSL (πρωτόκολλο HTTPS). Σε περίπτωση αιτήσεων μέσω HTTP θα γίνεται ανακατεύθυνση τους στο HTTPS.

17. Πλήρες Monitoring όλων των συστατικών του συστήματος

2.4.2. Τρόπος ανάπτυξης

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

2.4.3. Περιβάλλοντα

Απαραίτητα θεωρούνται τα Development (dev), UAT (User Acceptance Test) και Staging περιβάλλοντα πέραν της παραγωγής με όλα τα συστατικά (components) που περιγράφονται. Για τα dev και UAT μπορεί η φιλοξενία των συστατικών να γίνει σε ένα VM, αντίθετα το staging πρέπει να είναι ακριβές mirror της παραγωγής (δλδ ξεχωριστό VM για app server mid office, app server front office, message queue mid office, RDBMS κοκ).

Επίσης, απαιτείται εύκολο deploy κώδικα εφαρμογής και στα τρία περιβάλλοντα και ένα κοινό source tree για όλα τα περιβάλλοντα ώστε ο developer να μη χρειάζεται να αλλάζει αρχεία με παράμετρους όταν κάνει deploy στα τρία περιβάλλοντα αλλά να εκτελείται απ’ ευθείας μέσω επιλογής "deploy production/staging/UAT" και θα γίνεται το deploy στην παραγωγή/staging/UAT (αφού του ζητηθούν τα κατάλληλα credentials). Το source tree θα ανέβει στο VSC server του ΛΣ - ΕΛ. ΑΚΤ..

Ο ανάδοχος πρέπει να περιγράψει αναλυτικά τη διαδικασία εγκαταστάσεων για όλα τα συστατικά ξεκινώντας από ένα καθαρό VM με το λειτουργικό σύστημα που έχει επιλεγεί. Πρέπει να φαίνονται ξεκάθαρα οι διαφορές στις ρυθμίσεις στα περιβάλλοντα


Έργο ΑΝΝΑ

dev/uat/staging και prod και να επιδείξει, κατά τη διάρκεια των δοκιμών, τη διαδικασία δημιουργίας ενός πλήρους dev περιβάλλοντος σε συνάρτηση με τις οδηγίες εγκατάστασης.

2.4.4. Δομοστοιχεία λογισμικού

Αναφορικά με τη δομή του αναπτυσσόμενου λογισμικού για την ενιαία ναυτιλιακή θυρίδα δε θα υπάρχει ένα συγκεντρωτικό s/w project αλλά θα χωρίζεται σε διαφορετικά μικρότερα τμήματα τα οποία θα είναι τουλάχιστον τα εξής:

Γραφικό περιβάλλον Front office

Γραφικό περιβάλλον monitoring Front – Mid - Back office

Γραφικό περιβάλλον διαχείρισης της εφαρμογής

Γραφικό περιβάλλον υποσυστήματος πρόσβασης σε δεδομένα (Πιλοτικό έργο 4)

Web APIs Mid Office

Message broker

Ξεχωριστό s/w project για κάθε backend (διασύνδεση του Back-office).


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 3: Διακινούμενα δεδομένα

3.1. Μοντέλο Δεδομένων

Στο πλαίσιο του έργου ΑΝΝΑ, έχει αναπτυχθεί Μοντέλο Δεδομένων (Data Model), προκειμένου τα μεμονωμένα στοιχεία δεδομένων (data elements) που σχετίζονται με την οδηγία 2010/65/ΕΕ να δομηθούν με συγκεκριμένο τρόπο, προκειμένου να διευκολυνθεί η ομογενοποιημένη υλοποίηση της ενιαίας ναυτιλιακής θυρίδας κάθε κράτους. Τα στοιχεία δεδομένων που έχουν σχέση μεταξύ τους (data objects) έχουν ομαδοποιηθεί σε κλάσεις και οι κλάσεις αυτές, καθώς και οι μεταξύ τους σχέσεις αποτελούν το εν λόγω Μοντέλο Δεδομένων, το οποίο στηρίζεται στο αντίστοιχο Μοντέλο του Οργανισμού WCO, παρουσιάζεται στο Σχήμα 3.1.

Σχήμα 3.1 Μοντέλο δεδομένων του ΑΝΝΑ

Τα στοιχεία δεδομένων που περιλαμβάνονται σε κάθε κλάση του Μοντέλου Δεδομένων, περιγράφονται αναλυτικά στο Παράρτημα Ι του παρόντος.


Έργο ΑΝΝΑ

3.2. Δομή μηνυμάτων

Η ενιαία ναυτιλιακή θυρίδα θα υποστηρίζει μηνύματα (B2MSW – Bussiness to Maritime Single Window) που θα παρέχονται σε μορφή είτε XML, είτε EDIFACT. Τα μηνύματα αυτά θα περιλαμβάνουν δηλώσεις (declarations) και η αποστολή τους από τους υπόχρεους θα ικανοποιεί τις απαιτήσεις της οδηγίας για την υποβολή δηλώσεων. Κάθε δήλωση αποτελείται από στοιχεία δεδομένων και κάθε μία από τις διατυπώσεις υποβολής δηλώσεων σχετίζεται με μία ή περισσότερες δηλώσεις. Με τον τρόπο αυτό, η αλληλοεπικάλυψη των στοιχείων δεδομένων σε μεμονωμένες δηλώσεις ελαχιστοποιείται. Το μήνυμα B2MSW επιτρέπει την αποστολή όλων των απαιτούμενων τύπων δηλώσεων μέσω της αποστολής ενός μόνο μηνύματος. Στον Πίνακα 3.1 παρουσιάζεται μία επισκόπηση των δηλώσεων και των υποστηριζόμενων διατυπώσεων υποβολής δηλώσεων.

Πίνακας 3.1 Τύποι δηλώσεων και υποστηριζόμενων διατυπώσεων υποβολής δηλώσεων

Τύπος Δήλωσης Περιγραφή

Διατυπώσεις Υποβολής

Δηλώσεων1

NOA Αναγγελία προ-κατάπλου του πλοίου A.1, B.1COA Ακύρωση άφιξης του πλοίου A.1, B.1ETA Κοινοποίηση εκτιμώμενου χρόνου άφιξης του πλοίου A.1, B.1NOD Αναγγελία προ-απόπλου του πλοίου B.1ETD Κοινοποίηση εκτιμώμενου χρόνου αναχώρησης του πλοίου B.1ATA Κοινοποίηση ακριβούς χρόνου άφιξης του πλοίου Γ.2ATD Κοινοποίηση ακριβούς χρόνου απόπλου του πλοίου Γ.2EXP Κοινοποίηση εκτεταμένης επιθεώρησης Γ.1STO Δήλωση αποθηκευτικών χώρων επί του πλοίου B.3WAS Δήλωση αποβλήτων και καταλοίπων φορτίου επί του πλοίου A.4SEC Κοινοποίηση πληροφοριών σχετικών με την ασφάλεια A.5, B.9PAX Κοινοποίηση επιβαινόντων B.5, B.6MDH Ναυτιλιακή Δήλωση Υγείας (περιέχει γενικές πληροφορίες για τη

Ναυτιλιακή Δήλωση Υγείας)B.8

EFF Δήλωση προσωπικών ειδών πληρώματος B.4ENS Συνοπτική διασάφηση εισόδου A.6SDT Συνοπτική διασάφηση προσωρινής αποθήκευσης B.2HZA Αναφορά επικίνδυνων ή ρυπογόνων εμπορευμάτων κατά την άφιξη A.3, B.7HZD Αναφορά επικίνδυνων ή ρυπογόνων εμπορευμάτων κατά την

αναχώρησηA.3, B.7

Αναλυτικά στοιχεία για όλες τις δηλώσεις και τον τρόπο υλοποίησης των ανταλλασσόμενων μηνυμάτων περιλαμβάνονται στον «Οδηγό Υλοποίησης Μηνυμάτων» (Message Implementation Guide) που έχει αναπτυχθεί στο πλαίσιο του ΑΝΝΑ και αποτελεί το Παράρτημα Ι του παρόντος.

3.3. Απαιτήσεις Ομάδας eMS

1 Η συγκεκριμένη στήλη αναφέρεται στα μέρη Α και Β του Παραρτήματος της οδηγίας 2010/65/ΕΕ. Επιπλέον, η Κοινοποίηση εκτεταμένης επιθεώρησης καθορίζεται στο άρθρο 9 της οδηγίας 2009/16/EΚ και η Κοινοποίηση ακριβούς χρόνου απόπλου και κατάπλου του πλοίου στο άρθρο 24 της ίδιας οδηγίας.


Έργο ΑΝΝΑ

Στο πλαίσιο της Ομάδας eMS (παρ. 1.2.3 του παρόντος) έχει συσταθεί υποομάδα χαρτογράφησης δεδομένων (Data Mapping and Functionalities Sub-Group), η οποία έχει παραδώσει αναφορά σχετικά με τη χαρτογράφηση των δεδομένων που αφορούν στην οδηγία, καθώς και έγγραφο που περιλαμβάνει κατευθυντήριες οδηγίες για την υλοποίηση των εθνικών ενιαίων ναυτιλιακών θυρίδων. Τα εν λόγω έγγραφα δεν έχουν λάβει ακόμα έγκριση από το eMS, ωστόσο επίκειται επικαιροποίησή τους, με βάση τον προαναφερθέντα Οδηγό Υλοποίησης Μηνυμάτων και αναμένεται να τεθούν προς έγκριση στην 12η συνάντηση της ομάδας eMS, που είναι προγραμματισμένη για την 1η Ιουλίου 2014. Ο ανάδοχος θα πρέπει στην υλοποίησή του να συμμορφωθεί πλήρως με τις όποιες οδηγίες του eMS αναφορικά με την υλοποίηση της οδηγίας 2010/65/ΕΕ, όταν αυτές επικυρωθούν, καθώς και με τον Οδηγό Υλοποίησης Μηνυμάτων του ΑΝΝΑ. Σε περίπτωση που τα διαφορετικά κείμενα έρχονται σε σύγκρουση μεταξύ τους, θα δοθούν κατάλληλες οδηγίες από την ΕΠΕ. Για λόγους πληρότητας, οι τρέχουσες (μη εγκεκριμένες) εκδόσεις των εν λόγω εγγράφων της υποομάδας του eMS, παρατίθενται στα Παραρτήματα ΙΙΙ και IV του παρόντος.


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 4: Χρήστες Συστήματος

Η ενιαία ναυτιλιακή θυρίδα που θα δημιουργηθεί στο πλαίσιο του παρόντος, θα χρησιμοποιείται από τους ακόλουθους χρήστες:

Διαχειριστές συστήματος, οι οποίοι θα είναι κατάλληλα πιστοποιημένα άτομα του Α/ΛΣ-ΕΛΑΚΤ οι οποίοι και θα έχουν αυξημένες δυνατότητες ελέγχου στο σύστημα ώστε να βλέπουν τα διάφορα εργαλεία monitoring που θα προσφερθούν από τον ανάδοχο αλλά και θα λαμβάνουν ειδοποιήσεις από το σύστημα σε κάθε περίπτωση δυσλειτουργίας.

Διαχειριστές εφαρμογής, οι οποίοι θα είναι κατάλληλα πιστοποιημένα άτομα του Α/ΛΣ-ΕΛΑΚΤ και θα επιλύουν τυχόν προβλήματα στη λειτουργία της εφαρμογής και θα είναι υπεύθυνοι για την εγγραφή και δημιουργία των υπόλοιπων χρηστών του συστήματος.

Πολίτες, οι οποίοι θα κάνουν τις καταχωρήσεις στο GUI και θα είναι είτε πράκτορες, είτε κυβερνήτες των υπόχρεων πλοίων, είτε υπεύθυνοι εταιρειών διαχείρισης κλπ.

Χρήστες API (Μ2Μ) οι οποίοι θα χρησιμοποιούν κατάλληλα το API της ενιαίας ναυτιλιακής θυρίδας για την καταχώρηση των μηνυμάτων.

Χρήστες Φορέων (συμπεριλαμβανομένου και του ΛΣ-ΕΛΑΚΤ) στους οποίους θα παρέχεται πρόσβαση στα δεδομένα της ενιαίας ναυτιλιακής θυρίδας.

4.1. Πολιτική Δικαιωμάτων χρηστών συστήματος

Λαμβάνοντας υπόψη:

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

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

τις υποχρεώσεις που απορρέουν από την Κ.Ο 2010/65 - σχετικά με τη λήψη μέτρων διασφάλισης της εμπιστευτικότητας των πληροφοριών,

τη σχετική εθνική Νομοθεσία περί προστασίας δεδομένων προσωπικού χαρακτήρα και απορρήτου

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

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


Έργο ΑΝΝΑ

πληροφορίες των αντίστοιχων πλοίων και των αναφορών που έχουν καταχωρηθεί από τους ίδιους.

Θα πρέπει να είναι διακριτά τα δικαιώματα ανά κατηγορία χρηστών με δυνατότητα προσθήκης ή αφαίρεσης δικαιωμάτων από το διαχειριστή του συστήματος. Θα δημιουργηθεί φιλικό προς τον χρήστη γραφικό περιβάλλον μέσω του οποίου οι διαχειριστές του συστήματος θα μπορούν να εκτελούν τουλάχιστον τα κάτωθι:

• Πλήρης διαχείριση των στοιχείων των χρηστών του συστήματος με δυνατότητα επαναφοράς του κωδικού ασφαλείας (password) των χρηστών.

• Δυνατότητα αλλαγής της κατηγορίας (group) του κάθε χρήστη. Δυνατότητα προσθήκης ή αφαίρεσης μεμονωμένων δικαιωμάτων χρηστών, ανά χρήστη.

• Πλήρης διαχείριση (Προσθήκη, Επικαιροποίηση στοιχείων, αναζήτηση, Απενεργοποίηση-Ενεργοποίηση, Διαγραφή χρηστών από τους Διαχειριστές του συστήματος κ.α.).

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

• Ομαδοποίηση (groups) χρηστών ανάλογα με το επίπεδο της ασφάλειας και διαχείριση της πολιτικής πρόσβασης μέσω των ομάδων αυτών με συγκεκριμένα δικαιώματα

• Παραμετροποίηση και ελέγχου του συστήματος μέσω φιλικού γραφικού περιβάλλοντος

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

• Δυνατότητα ενεργοποίησης και τήρησης ενιαίας αναλυτικής καταγραφής όσων λειτουργιών κριθούν απαραίτητες που εκτελεί κάθε χρήστης στο σύστημα (audit trail)

• Δυνατότητα αντιγραφής ‘προφίλ ασφάλειας’ ομάδας χρηστών ή χρήστη σε άλλες ομάδες χρηστών ή χρήστες

• Δυνατότητα ταυτοποίησης των χρηστών με τη χρήση ψηφιακού πιστοποιητικού

• Διαχείριση στοιχείων πλοίων

• Ότι άλλο καθοριστεί από τη Μελέτη Εφαρμογής

• Καταχώρηση, ενημέρωση και διαγραφή πληροφοριών (test data) ώστε να επιτρέπεται η πλήρης προσομοίωση της διαδικασίας συγκέντρωσης των πληροφοριών και να επιτυγχάνεται η διενέργεια ελέγχων της ορθής λειτουργίας του συστήματος. Τα δεδομένα αυτά (test data) θα πρέπει να αποθηκεύονται με ιδιαίτερο τρόπο (flagging) ώστε να είναι εύκολα αναζητήσιμα. Στο πλαίσιο αυτό θα πρέπει να προσομοιώνεται πλήρως και η αποστολή των πληροφοριών στο κεντρικό σύστημα.

4.2. Δημιουργία και διαχείριση βάσης δεδομένων πλοίων


Έργο ΑΝΝΑ

Σε πρώτη φάση για την πλήρωση της βάσης δεδομένων πλοίων του συστήματος θα αξιοποιηθεί η βάση πλοίων του EMSA και η οποία θα παρασχεθεί από το Φορέα. Ο ανάδοχος θα υλοποιήσει αυτόματη διαδικασία για την ανανέωση των στοιχείων της εν λόγω βάσης.

Ο ανάδοχος θα καθορίσει τη διαδικασία που θα ακολουθηθεί σε περίπτωση που δεν υφίσταται στη βάση δεδομένων το πλοίο για το οποίο πρόκειται να υποβληθούν αναφορές.

Η Διαχείριση των στοιχείων των πλοίων η οποία συνίσταται ενδεικτικά στην εισαγωγή, ενημέρωση/τροποποίηση, διαγραφή, αναζήτηση, παρουσίαση, των στοιχείων των πλοίων, πέραν της προαναφερθείσας αυτόματης διαδικασίας που θα υλοποιηθεί, θα υπάρχει δυνατότητα να γίνεται και από το προσωπικό των Υπηρεσιών του ΛΣ-ΕΛ.ΑΚΤ.

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

Σε περίπτωση που απαιτείται η ενημέρωση στοιχείων πλοίου ή η εισαγωγή νέου πλοίου από χρήστη που δεν έχει το σχετικό δικαίωμα, θα αποστέλλεται με τυποποιημένο τρόπο μέσω της διεπαφής του συστήματος σχετικό ηλεκτρονικό αίτημα στους διαχειριστές ή σε αρμόδια Υπηρεσία του Φορέα, με σκοπό να ελεγχθεί η τροποποίηση και να εκτελεστεί το συντομότερο δυνατό.

Το περιβάλλον Διαχείρισης των στοιχείων των πλοίων θα επιτρέπει την Εισαγωγή, Αναζήτηση, Ανάκτηση, Ενημέρωση, Διόρθωση & Διαγραφή των ακολούθων τουλάχιστον στοιχείων πλοίων:

• Αριθμός IMO: 7ψήφιος αριθμός (IMO Number, υποχρεωτικός και μοναδικός για κάθε πλοίο σύμφωνα με τον σχετικό αλγόριθμο ελέγχου εγκυρότητας (δεν επιτρέπεται η ταυτόχρονη ύπαρξη στη βάση δύο διαφορετικών στοιχείων πλοίων με τον ίδιο αριθμό ΙΜΟ).

• Αριθμός MMSI: 9ψήφιος αριθμός (SSN - MMSI Number, υποχρεωτικός εάν δεν καταχωρηθεί αριθμός IMO. Τα τρία (3) πρώτα ψηφία εξαρτώνται από τη σημαία του πλοίου)

• ΔΔΣ: 1 – 7 Χαρακτήρες, Υποχρεωτικό (Call Sign)• Όνομα Πλοίου: 1 – 35 Λατινικοί χαρακτήρες, Υποχρεωτικό (Ship Name)• Σημαία • Λιμένας Νηολογίου: Λατινικοί χαρακτήρες• Αριθμός Νηολογίου• Τύπος Πλοίου: Λατινικοί χαρακτήρες• Ο.Χ. (GT)• Ολικό Μήκος• Βύθισμα

Ανεξάρτητα από τα παραπάνω, σε κάθε περίπτωση, θα τηρείται πλήρης ιστορικότητα των στοιχείων κάθε πλοίου όπως αυτά υπήρχαν ή ενημερώθηκαν κατά τη στιγμή υποβολής


Έργο ΑΝΝΑ

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

Τέλος, για τις λειτουργίες διαχείρισης στοιχείων Πλοίων θα υλοποιηθούν επιπλέον τα κάτωθι:

• Θα παρέχεται δυνατότητα αναζήτησης στοιχείων βάσει ενός ή συνδυασμού περισσοτέρων από τα παραπάνω στοιχεία.

• Εφόσον χρησιμοποιούνται αριθμητικά πεδία (π.χ. για το ΙΜΟ), η αναζήτηση θα μπορεί να γίνεται ακόμη και αν δεν έχουν συμπληρωθεί στο πεδίο όλα τα ψηφία του αριθμού, επιστρέφοντας τα κοινά αποτελέσματα.

• Με τη λειτουργία αναζήτησης θα παρουσιάζονται όλα τα στοιχεία της ανωτέρω παραγράφου.

• Θα παρέχεται δυνατότητα ενημέρωσης ή διόρθωσης του αριθμού IMO, τηρώντας την ιστορικότητα των αλλαγών, στην “καρτέλα” που περιέχει το σύνολο των στοιχείων πλοίων.

• Για όλες τις περιπτώσεις Εισαγωγής, Ενημέρωσης Διόρθωσης & Διαγραφής στοιχείων θα ζητείται ρητή επιβεβαίωση από τον χειριστή (pop up message) ενώ θα καταγράφονται τα στοιχεία του χρήστη καθώς και η ημερομηνία και ώρα της κίνησης (logs).

4.3. Κωδικοί UNECE/LOCODE

Ο Ανάδοχος θα ενσωματώσει τη βάση δεδομένων κωδικών UNECE/LOCODE των λιμένων (function 1) από την επίσημη ιστοσελίδα του EMSA στη Βάση Λιμένων (Locode, Location name, συντεταγμένες) του συστήματος, τόσο για τους Ελληνικούς λιμένες όσο και για λιμένες των υπόλοιπων χωρών, δίνοντας τη δυνατότητα στους διαχειριστές του συστήματος να μπορούν απευθείας να εισάγουν νέες τοποθεσίες και κωδικούς και να επεξεργάζονται τις υπάρχουσες κρατώντας ιστορικό αλλαγών.

4.4. Διαδικασία δημιουργίας εξωτερικού χρήστη

Πρέπει να υπάρχει διαδικασία δημιουργίας νέων εξωτερικών χρηστών στο σύστημα. Η Ενιαία Ναυτιλιακή Θυρίδα μέσω του Front Office θα πρέπει να προσφέρει δυνατότητες αίτησης για δημιουργία νέου χρήστη η οποία μέσω κατάλληλης ροής εργασίας (workflow) θα εγκρίνεται ή θα απορρίπτεται από τους διαχειριστές εφαρμογής οι οποίοι θα ελέγχουν εξωσυστημικά την κάθε αίτηση. Η φόρμα δημιουργίας χρήστη θα πρέπει να έχει τα ακόλουθα πεδία:

Ονοματεπώνυμο χρήστη

Εταιρεία που εκπροσωπεί

E-mail

Τηλέφωνα

Διεύθυνση


Έργο ΑΝΝΑ

Η ροή προς υλοποίηση έχει ως εξής: Ο χρήστης εκκινεί στην αρχική σελίδα του F.O τη διαδικασία εγγραφής χρήστη. Αφού συμπληρώσει και αποστείλει τη φόρμα, του εμφανίζεται κατάλληλο μήνυμα στην οθόνη με περιεχόμενο της μορφής: «Σας έχει αποσταλεί ένα e-mail για έλεγχο της διεύθυνσης e-mail που εισάγατε, παρακαλώ δείτε τα εισερχόμενα σας και ακολουθήστε τη σύνδεση που υπάρχει στο e-mail», ενώ ταυτόχρονα του έχει αποσταλεί e-mail το οποίο περιέχει κείμενο της μορφής: «Παρακαλούμε ακολουθήστε την παρακάτω σύνδεση για επιβεβαίωση του e-mail σας». Τα μηνύματα θα πρέπει να είναι παραμετροποιήσιμα από τους Διαχειριστές.

Όταν ο χρήστης ακολουθήσει τη σύνδεση θα επιβεβαιωθεί το e-mail του και μόνο τότε θα έρθει ειδοποίηση προς τους Διαχειριστές της εφαρμογής ώστε να μπουν σε ειδική οθόνη η οποία θα εμφανίζει τα αιτήματα εγγραφής νέου χρήστη. Η εν λόγω οθόνη θα εμφανίζει όλα τα αιτήματα και τα στοιχεία που έχουν συμπληρωθεί με σαφή ένδειξη για τα αιτήματα που έχουν επιβεβαιώσει το e-mail τους και για αυτά που έχουν ήδη εγκριθεί. Οι διαχειριστές με εξωσυστημικό τρόπο θα ελέγχουν τα στοιχεία του αιτήματος και θα επιλέγουν έγκριση ή απόρριψη. Σε περίπτωση απόρριψης θα πρέπει να καταχωρείται ειδικό μήνυμα ώστε να δικαιολογείται η απόφαση τους το οποίο και θα αποθηκεύεται με τα υπόλοιπα στοιχεία της αίτησης. Σε περίπτωση έγκρισης θα αποστέλλεται αυτόματα στο e-mail του χρήστη μήνυμα το οποίο θα περιλαμβάνει σύνδεση προς μοναδικό URL μέσω του οποίου θα μπορεί να δημιουργήσει κωδικό στο σύστημα.

Σημειώνεται ότι θα πρέπει να γίνεται επαναποστολή των ειδοποιήσεων τόσο προς τους πολίτες για την επιβεβαίωση του e-mail τους μετά από καθοριζόμενο από τους διαχειριστές του συστήματος χρόνο (πχ μετά από 1 ημέρα και μετά από 1 εβδομάδα) αλλά και προς τους διαχειριστές της εφαρμογής για αιτήσεις τις οποίες δεν έχουν εγκρίνει / απορρίψει μετά από ομοίως καθοριζόμενο χρόνο.

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

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

4.5. Χρήστες Φορέων που έχουν πρόσβαση στα δεδομένα της ενιαίας ναυτιλιακής θυρίδας

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

Αναφορές και τα επιμέρους πεδία αυτών Γεωγραφική περιοχή αρμοδιότητας.


Έργο ΑΝΝΑ

Για την κάλυψη των ανωτέρω απαιτήσεων θα πρέπει να μπορούν οι διαχειριστές του συστήματος να διαμορφώνουν τις προβαλλόμενες πληροφορίες βάση του Data Model οι οποίες θα περιλαμβάνουν επιλεγμένα στοιχεία δεδομένων της ενιαίας ναυτιλιακής θυρίδας. Ομοίως, θα καθοριστεί με τη συνδρομή των αρμόδιων Υπηρεσιών, η γεωγραφική περιοχή αρμοδιότητας κάθε χρήστη εξωτερικού Φορέα με βάση τα LOCODES των λιμανιών που ανήκουν στη δικαιοδοσία του.

Θα παρέχεται στους διαχειριστές του συστήματος η δυνατότητα καθορισμού γενικών κανόνων πρόσβασης σε κάθε ομάδα ή χρήστη και με γεωγραφικά κριτήρια αλλά και με κριτήρια είδους πληροφοριών (π.χ. οι χρήστες ενός Οργανισμού Λιμένα θα διαθέτουν πρόσβαση μόνον στα στοιχεία αναφορών πλοίων που καταπλέουν ή αποπλέουν σε/από λιμάνι της περιοχής δικαιοδοσίας τους ενώ παράλληλα μπορεί να μην τους παρασχεθεί πρόσβαση στα στοιχεία των αναφορών Security πλοίων ή στις πληροφορίες των μεταφερόμενων φορτίων των αναφορών ΗΑΖΜΑΤ).

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

4.6. Διαδικασία δημιουργίας χρήστη Machine to Machine

Η διαδικασία πιστοποίησης χρήστη M2M ώστε να συνδεθεί το πληροφοριακό σύστημα του υπόχρεου με την ενιαία ναυτιλιακή θυρίδα θα πραγματοποιείται εξωσυστημικά όπως αυτή καθοριστεί από την αρμόδια Υπηρεσία. Οι διαχειριστές του συστήματος θα μπορούν να προσθέτουν το API KEY και το IP του server και τα πιστοποιητικά ασφαλείας του υπόχρεου μέσω του GUI διαχείρισης.

4.7. Ασφάλεια κωδικών

Για τους μεν χρήστες θα δημιουργούνται ζεύγη username / password, με username το e-mail που θα δηλώσουν και password ο οποίος έχει κατάλληλα χαρακτηριστικά. Οι χρήστες θα μπορούν να τον αλλάξουν χωρίς την παρέμβαση των διαχειριστών εφαρμογής, δηλαδή με δημιουργία και αποστολή κατάλληλου email με σύνδεση προς σελίδα εισαγωγής νέου κωδικού αλλά θα γίνεται έλεγχος ότι πληρούνται προϋποθέσεις ασφάλειας για τους κωδικούς, ήτοι: ελάχιστο μήκος, ελάχιστος αριθμός κεφαλαίων γραμμάτων ελάχιστος αριθμός πεζών γραμμάτων, ελάχιστος αριθμός αριθμητικών ψηφίων, ελάχιστος αριθμός σημείων στίξης -- τα προηγούμενα πρέπει να είναι παραμετροποιήσιμη από τους διαχειριστές. Ομοίως θα πρέπει να είναι παραμετροποιήσιμη από τους διαχειριστές η επιλογή τυχόν ημερομηνίας λήξης του κωδικού των χρηστών. Για τους χρήστες workflows, θα δημιουργούνται ζεύγη IP / API KEYS όπου τα API KEYS θα είναι τυχαίοι κωδικοί >128 bit (δηλαδή τουλάχιστον 8 hex digits).

Κανένας κωδικός ή API KEY δε θα αποθηκεύεται στη ΒΔ με plain text αλλά μόνο αφού γίνει κατάλληλο hashing και ως εκ τούτου όλοι οι κωδικοί που εισάγονται από τους χρήστες ή έρχονται μέσω του API θα πρέπει να ελέγχονται μέσω της hashed μορφής τους.

Θα πρέπει να υπάρχει ρύθμιση από τους διαχειριστές του συστήματος για το χρόνο που θα μπορεί να διαρκέσει το κάθε session του χρήστη (δηλαδή πόση ώρα θα μπορεί να μείνει


Έργο ΑΝΝΑ

ανενεργός ένας χρήστης χωρίς να πραγματοποιήσει κάποια ενέργεια και πριν το σύστημα τον αποσυνδέσει αυτόματα) με αρχική διάρκεια τα 15 λεπτά.

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


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 5: Πιλοτικό έργο 1 - Front Office

5.1. Εισαγωγή

Το Front Office (στο εξής F.O) του έργου Anna είναι το τμήμα το οποίο είναι υπεύθυνο με την αλληλεπίδραση με τους εξωτερικούς χρήστες, είτε αυτοί είναι μεμονωμένα άτομα, υπόχρεα προς καταχώρηση στοιχείων πλοίων είτε είναι οι αυτοματοποιημένες ροές εργασιών των εταιρειών διαχείρισης των πλοίων οι οποίες και ενημερώνουν το F.O χωρίς την παρέμβαση ατόμων. Σε όλες τις περιπτώσεις, το F.O αποτελεί την πρώτη πύλη εισόδου της πληροφορίας στο σύστημα με κύρια χαρακτηριστικά:

Την διασφάλιση της ακεραιότητας των δεδομένων που εισάγονται

Την ασφάλεια του συστήματος από εξωτερικές επιθέσεις

Την ευκολία χρήσης του συστήματος

Την ταχύτητα απόκρισης

Την υποστήριξη μεγάλου αριθμού ταυτόχρονων χρηστών

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

5.2. Γενική αρχιτεκτονική

Η βασική λειτουργία του F.O είναι η εξής: Οι υπόχρεοι, είτε είναι πραγματικοί χρήστες είτε άλλα υπολογιστικά συστήματα θα συνδέονται στο F.O και θα καταχωρούν τις πληροφορίες που αφορούν στα πλοία τους. Οι μεν πραγματικοί χρήστες χρησιμοποιώντας το GUI, τα δε συστήματα χρησιμοποιώντας κατάλληλο API το οποίο παρέχεται από το Mid Office (άρα το F.O προωθεί την επικοινωνία με το εν λόγω API) και στέλνοντας μηνύματα, όπως περιγράφονται στο Παράρτημα I. Στην περίπτωση του GUI θα ακολουθεί μετατροπή των δεδομένων που εισήχθησαν στα μηνύματα που περιγράφονται στο Παράρτημα I. Σε κάθε περίπτωση, τα μηνύματα της μορφής του Παραρτήματος I θα προωθούνται στο Mid Office. Πρέπει να υπάρχει εδώ πρόβλεψη για αποθήκευση των μηνυμάτων σε τοπική ΒΔ/ουρά σε περίπτωση που χαθεί η επικοινωνία με το mid office ώστε να προωθηθούν εκεί όταν επανέλθει η επικοινωνία.

Το F.O πρέπει να είναι ένα Web-based, Enterprise λογισμικό σύστημα αποτελούμενο από τουλάχιστον 3 αρχιτεκτονικά επίπεδα (3-tiered architecture): Παρουσίαση (presentation tier), Εφαρμογή (application/business tier) και Δεδομένα (data tier). Τα τρία αυτά επίπεδα θα πρέπει να υλοποιούνται σε διαφορετικά συστήματα λογισμικού (δηλαδή ο Web server θα πρέπει να είναι διαφορετικός από τον Application server και διαφορετικός από τον Database server) και απαραιτήτως το data tier να βρίσκεται σε ξεχωριστή εικονική μηχανή από τα άλλα δύο επίπεδα. Τα άλλα δύο επίπεδα μπορούν να βρίσκονται είτε σε ξεχωριστές είτε στην ίδια εικονική μηχανή, με προτίμηση όμως να βρίσκονται στην ίδια εικονική μηχανή για λόγους ευκολίας όπως θα φανεί στην επόμενη παράγραφο.


Έργο ΑΝΝΑ

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

To data tier θα πρέπει να υποστηρίζει την αυτόνομη λειτουργία του Front Office για τουλάχιστον 12 ώρες σε περίπτωση που χαθεί η επικοινωνία με το Mid Office.

Μπροστά από το επίπεδο της παρουσίασης θα πρέπει να υπάρχει (σε διαφορετικό κόμβο) ένας κατανεμητής φορτίου (load balancer + εφεδρικός), ο οποίος και θα προωθεί κατάλληλα την κίνηση στους αντίστοιχους κόμβους παρουσίασης.

5.3. Λειτουργικές απαιτήσεις του GUI

Βασική απαίτηση του GUI είναι να είναι εύχρηστο, γρήγορο και συμβατό με όσο γίνεται περισσότερους φυλλομετρητές (browsers). Πρέπει να έχει αναπτυχθεί με όλες τις σύγχρονες τεχνολογίες Web 2.0. Μερικά από τα χαρακτηριστικά που πρέπει οπωσδήποτε να περιλαμβάνει:

Κατάτμηση σε φόρμες με τη μορφή πλακιδίων (tiles) ή αντίστοιχης παρουσίασης

Δυνατότητες προσωρινής αποθήκευσης των πληροφοριών πριν την οριστική υποβολή τους

Έλεγχοι τόσο σε client side (javascript) ώστε να αποφεύγονται άσκοπα requests προς το server όσο και σε server side

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

Για την αυτόματη συμπλήρωση θα πρέπει να μπορεί να χρησιμοποιηθούν και στοιχεία προηγούμενων αιτήσεων

Εύκολη εναλλαγή μεταξύ ελληνικών και αγγλικών από το χρήστη.

Καθαρός και εύκολος στην κατανόηση σχεδιασμός

Κατατοπιστικά μηνύματα σφάλματος, επιτυχίας, πληροφορίας με αντίστοιχους χρωματισμούς

Πλήρης υποστήριξη όλων των σύγχρονων browsers: Internet Explorer >= 9, Chrome, Firefox, Opera, Safari καθώς και κινητών συσκευών των γνωστότερων τύπων, με ελάχιστη απαίτηση υποστήριξης των iOS, Android και Windows Phone.

Στο πλαίσιο του έργου ANNA έχει υλοποιηθεί πιλοτικά ένα πλήρες γραφικό περιβάλλον εργασίας για το οποίο διατίθεται ο πηγαίος κώδικας, υλοποιηθείς σε HTML 5 / CSS / Javascript. Το εν λόγω GUI δύναται να αποτελέσει τη βάση ανάπτυξης του GUI της ελληνικής ενιαίας ναυτιλιακής θυρίδας με τις απαραίτητες προσθήκες και τροποποιήσεις ακολουθώντας τις προδιαγραφές της διακήρυξης. Επιπλέον σε κάθε περίπτωση η υλοποίηση θα πρέπει να είναι ισοδύναμη η τεχνικά ανώτερη του προσφερόμενου GUI,


Έργο ΑΝΝΑ

προσφέροντας κατ’ ελάχιστον την ίδια λειτουργικότητα και εμφάνιση/παρουσίαση. Στα παρακάτω Σχήματα παρουσιάζονται ενδεικτικά στιγμιότυπα οθόνης (screenshots) του εν λόγω GUI, τόσο σε σύστημα desktop, όσο και σε σύστημα mobile.

Σχήμα 5.1 Αρχική σελίδα του GUI του ΑΝΝΑ

Σχήμα 5.2 Στιγμιότυπο οθόνης του GUI του ΑΝΝΑ


Έργο ΑΝΝΑ




Έργο ΑΝΝΑ

Σχήμα 5.5 Στιγμιότυπο οθόνης του GUI του ΑΝΝΑ για συσκευή mobile

5.4. Μαζική εισαγωγή

Σε περίπτωση εισαγωγής πολλαπλών και επαναλαμβανόμενων πληροφοριών, όπως για παράδειγμα στα στοιχεία των επιβατών ή του πληρώματος είναι υποχρεωτική η δυνατότητα μαζικής εισαγωγής των στοιχείων με τη βοήθεια ενός αρχείου τύπου πίνακα με υποστήριξη τουλάχιστον των προτύπων xls, odf, csv. Η αναλυτική ροή για τη συγκεκριμένη δυνατότητα είναι η εξής: Όταν πρέπει να εισαχθούν επαναλαμβανόμενες πληροφορίες υπό μορφή πίνακα, εκτός από τη διεπαφή μέσω του GUI για την εισαγωγή των πληροφοριών θα δίνεται η δυνατότητα στον καταχωρητή να ανεβάσει στο F.O ένα αρχείο πίνακα κατάλληλης μορφής το οποίο θα περιέχει τα ζητούμενα στοιχεία. Το GUI θα διαβάζει (parsing) το αρχείο και θα συμπληρώνει αυτόματα τη φόρμα με τα στοιχεία του αρχείου, τα οποία και στη συνέχεια θα μπορεί ο καταχωρητής να ελέγξει. Πρέπει να δοθεί ιδιαίτερη προσοχή από τον ανάδοχο στην ευχρηστία της εν λόγω λειτουργίας ενώ υποχρεούται να τεκμηριώσει και επιδείξει στην ΕΠΕ την ορθή λειτουργία του συστήματος με ανέβασμα ενός αρχείου τουλάχιστον 5 000 εγγραφών. Δεν πρέπει δηλαδή να παρατηρούνται καθυστερήσεις από την πλευρά του χρήστη στη λειτουργία ακόμα και όταν συμπληρωθεί αυτός ο αριθμός των στοιχείων.

Όταν ανεβαίνει κάποιο αρχείο θα πρέπει να εμφανίζεται στο χρήστη ευκρινές progress bar το οποίο να του δείχνει τόσο το χρόνο που απομένει μέχρι να ανέβει το αρχείο στο server, όσο και το χρόνο που απομένει μέχρι να γίνει parse το αρχείο και να συμπληρωθεί η φόρμα.

5.5. Ταχύτητα απόκρισης

Όπως ήδη έχει γίνει φανερό, είναι σημαντικό το F.O να απαντά άμεσα στους καταχωρητές και καμία ενέργεια τους να μη χρειάζεται παραπάνω από 2 δευτερόλεπτα


Έργο ΑΝΝΑ

εκτός από τη μαζική εισαγωγή η οποία όπως αναφέρθηκε θα έχει κατάλληλο progress bar ώστε να ξέρουν πόσος χρόνος χρειάζεται. Σε κάθε περίπτωση ο χρήστης του συστήματος θα πρέπει να έχει πληροφόρηση για την εξέλιξη της κάθε ενέργειας του ώστε να αποφεύγονται νεκρά διαστήματα. Ως εκ τούτου, θα πρέπει ο ανάδοχος να τεκμηριώσει και επιδείξει στην ΕΠΕ τους χρόνους απόκρισης και γενικότερα συμπεριφοράς του συστήματος υπό συνθήκες φόρτου σύμφωνα με σενάρια δοκιμών που θα προταθούν από τον ανάδοχο στη μελέτη εφαρμογής.

5.6. Ροή καταχώρησης

Όταν κάποιος εξωτερικός χρήστης του συστήματος (υπόχρεος) πρόκειται να κάνει μια καταχώρηση, αρχικά επισκέπτεται την κεντρική σελίδα του συστήματος όπου και συνδέεται με τα credentials που διαθέτει. Στη συνέχεια και αφού το σύστημα τον καλωσορίσει με τα στοιχεία του, θα του εμφανίζεται το περιβάλλον καταχώρησης. Εδώ θα μπορεί να καταχωρήσει όλα τα στοιχεία που θέλει, με όποια σειρά επιθυμεί να πατήσει Προσωρινή αποθήκευση όσες φορές θέλει. Κατά την προσωρινή αποθήκευση θα πρέπει να γίνονται έλεγχοι και να εμφανίζεται κατάλληλο μήνυμα για τα λάθη που τυχόν έχουν γίνει όχι όμως για στοιχεία που λείπουν διότι αυτά μπορεί να μην έχει προλάβει να τα συμπληρώσει ακόμη. Μετά την προσωρινή αποθήκευση θα πρέπει να φαίνονται όλα τα στοιχεία που έχουν καταχωρηθεί ως τώρα. Η διεπαφή θα πρέπει να του εμφανίζει ξεκάθαρα το ποια στοιχεία είναι απαραίτητα να συμπληρωθούν και ποια στοιχεία έχουν εσφαλμένα στοιχεία. Όπως αναφέρθηκε και πριν θα πρέπει όσοι έλεγχοι μπορούν να γίνουν με Javascript (client side) να γίνονται ώστε να μην πραγματοποιούνται άσκοπα αιτήματα (requests) στους servers του F.O.

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

Ο χρήστης όταν θεωρεί ότι έχει συμπληρώσει τη φόρμα θα πατάει οριστική υποβολή η οποία θα ρωτά το χρήστη με κατάλληλο μήνυμα το οποίο πρέπει να έχει το γενικότερο styling της σελίδας αν θέλει πράγματι να υποβάλει τις πληροφορίες.

Όταν ο χρήστης αποδεχτεί την οριστική υποβολή, θα δημιουργείται ένα κατάλληλο μήνυμα της μορφής του Παραρτήματος I, το οποίο και θα προωθείται στο Mid Office. Σε περίπτωση που υπάρχουν σφάλματα κατά τους ελέγχους θα επιστρέφεται πίσω στο χρήστη κατάλληλο μήνυμα. Σε αντίθετη περίπτωση το μήνυμα θα εισάγεται στην ουρά μηνυμάτων του Mid Office και ομοίως ο χρήστης θα ενημερώνεται για την αποδοχή του μηνύματος από το σύστημα.

5.7. Διενέργεια ελέγχων κατά την καταχώρηση

Κατά την καταχώρηση πληροφοριών από το χρήστη, θα πραγματοποιείται από το σύστημα σειρά ελέγχων, ώστε να αποτρέπονται εσφαλμένες καταχωρήσεις. Ειδικότερα:


Έργο ΑΝΝΑ

Δεν θα επιτρέπεται ο πραγματικός χρόνος κατάπλου ενός πλοίου να είναι μεταγενέστερος ή ίδιος με το χρόνο απόπλου αυτού.

Ο IMO του πλοίου μέσω αυτόματης συμπλήρωσης ώστε να μη γίνονται σφάλματα.

Δε θα επιτρέπεται η καταχώρηση κωδικού LOCODE πέραν όσων βρίσκονται στη λίστα του EMSA (παρ. 4.3), εκτός αυτών που αντιστοιχούν σε μη γνωστούς λιμένες και απεικονίζονται με το διψήφιο λατινικό κωδικό της χώρας, ακολουθούμενο από τον αριθμό 888 (πχ. GR888 για άγνωστο λιμένα στην Ελλάδα), ή όσων χαρακτηρίζονται ως «SSN Specific» σύμφωνα με τις οδηγίες του EMSA.

Θα εμφανίζεται προειδοποιητικό μήνυμα σε περίπτωση που για κάποιο πλοίο παρέλθει ο εκτιμώμενος χρόνος κατάπλου (ETA) ή απόπλου (ETD), και δεν έχει καταχωρηθεί o ακριβής χρόνος κατάπλου (ATA) ή απόπλου (ATD). Για την ανωτέρω περίπτωση να δημιουργείται λίστα με τα ταξίδια αυτά που θα είναι διαθέσιμη στον καταχωρητή της αναφοράς, στη λιμενική αρχή αρμοδιότητας και κεντρικά στο SSN/NCA 24/7

Θα εμφανίζεται προειδοποιητικό μήνυμα σε περίπτωση που γίνει οποιαδήποτε καταχώρηση για πλοίο που του έχει απαγορευτεί η πρόσβαση (banned).

Κατά τη σύνταξη της Μελέτης Εφαρμογής του έργου θα προσδιοριστούν επιπλέον έλεγχοι αντίστοιχοι των ανωτέρω, αν αυτό απαιτηθεί.


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 6: Πιλοτικό έργο 2 - Mid Office

6.1. Εισαγωγή

Το Mid office του ΑΝΝΑ αποτελεί τον κεντρικό κόμβο αποθήκευσης δεδομένων του εν λόγω έργου. Η γενικότερη λειτουργία του έχει ως εξής: Τα μηνύματα που φθάνουν από το Front Office γίνονται validate και, σε περίπτωση που περάσουν τον έλεγχο, αποθηκεύονται σε μια κεντρική ουρά μηνυμάτων χωρίς να υποστούν κάποια άλλη επεξεργασία. Ακολούθως, μια ξεχωριστή διαδικασία (διαχείριση μηνυμάτων) αδειάζει την ουρά και συνεχίζει την επεξεργασία του κάθε μηνύματος. Συγκεκριμένα, το κάθε μήνυμα αρχικά αντιγράφεται ως έχει σε κατάλληλο File Repository και ακολούθως, γίνεται parse (διαβάζεται) και εισάγεται στους κατάλληλους πίνακες της βάσης δεδομένων του Mid office. Τέλος, ανάλογα και με το είδος του μηνύματος πραγματοποιείται η επικοινωνία με τα επιμέρους Back ends των άλλων Φορέων με σκοπό τη διάχυση αυτής της πληροφορίας. Πέραν της παραπάνω κεντρικής ροής, το Mid office περιέχει διάφορες επιμέρους ροές για χειρισμό αποτυχιών αυτόματα ή από τους διαχειριστές του συστήματος, διαχείριση και έλεγχο του συστήματος και πρόσβασης σε όλα του τα δεδομένα μέσω ανοιχτού API.

6.2. Αρχιτεκτονική

Το Mid office είναι μια Enterprise Web εφαρμογή αποτελούμενη από τρία ξεχωριστά επίπεδα: Web, Application και Database/Storage. Το επίπεδο Web ουσιαστικά προσφέρει ένα επίπεδο παρουσίασης για τη διαχείριση και το Monitoring του συστήματος καθώς και όλα τα απαραίτητα APIs με τη βοήθεια και του Application layer το οποίο και αποθηκεύει τα domain objects και το business logic της εφαρμογής και χρησιμοποιείται ως ενδιάμεση πρόσβαση προς το επίπεδο της αποθήκευσης.

Τα επίπεδα Web και Application είναι τα καθιερωμένα που υφίστανται στις Enterprise web εφαρμογές (δηλαδή προσφέρονται μέσω ενός web server και ενός application server με το κατάλληλο business layer). Για το επίπεδο της αποθήκευσης όμως, το Mid office χρειάζεται τρία ξεχωριστά compenents τα οποία και τα τρία θα είναι προσβάσιμα μέσω του Application layer:

File storage για την αποθήκευση όλων των αρχείων μηνυμάτων που έρχονται προς το Mid office αλλά και των απαντήσεων που δημιουργεί και στέλλει το Mid office

Database (RDBMS) για την αποθήκευση των business objects που θα γίνονται parse από τα μηνύματα καθώς και του πλήρους ιστορικού αυτών.

Message queues για την προσωρινή αποθήκευση των μηνυμάτων πριν αυτά γραφτούν στο file storage και γίνουν parse καθώς και των tasks (ενεργειών) που πρέπει να πραγματοποιηθούν μετά από κάποιο χρονικό διάστημα.

6.3. Χειρισμός Μηνυμάτων

Όπως αναφέρθηκε και παραπάνω, το Mid office δέχεται τα μηνύματα από το Front office. Αυτά τα μηνύματα μπορεί είτε να δημιουργηθούν μέσω του GUI του Front office όπως έχει αναλυθεί είτε να έχουν δημιουργηθεί από τα πληροφοριακά συστήματα των


Έργο ΑΝΝΑ

υπόχρεων εταιρειών και το Front office απλώς να τα προωθεί στο Mid Οffice. Σε κάθε περίπτωση, το Mid office δεν έχει απευθείας επικοινωνία με τον έξω κόσμο αλλά μόνον μέσω του Front office.

Η συμπεριφορά του Mid office για τα εισερχόμενα μηνύματα πρέπει να είναι η ίδια είτε τα μηνύματα προέρχονται από το Front office είτε προέρχονται από εξωτερικό σύστημα:

Γίνεται έλεγχος του μηνύματος με τη βοήθεια του message XML schema. Το μήνυμα πρέπει να είναι συμβατό με το συγκεκριμένο XML schema και με τους ελεγχους ακεραιότητας που θα ορισθούν από τους φορείς της Διοίκησης που είναι λήπτες των δεδομένων. Οι έλεγχοι αυτοί θα καθορισθούν λεπτομερώς στη φάση της μελέτης εφαρμογής του Αναδόχου.

Αν το εισερχόμενο μήνυμα είναι μορφής EDIFACT θα πρέπει να γίνεται μετατροπή αυτού σε XML για εσωτερική χρήση. Στη συνέχεια της ροής θα χρησιμοποιείται αυτό το XML για τους ελέγχους, parsing κλπ. Τα απαντητικά μηνύματα που στέλνονται από το Mid office (είτε απόρριψης είτε αποδοχής) πρέπει να είναι ίδιας μορφής με τα εισερχόμενα, π.χ. αν το εισερχόμενο μήνυμα είναι μορφής EDIFACT, θα πρέπει και το απαντητικό να είναι EDIFACT.

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

Αν το μήνυμα περάσει τον έλεγχο από το messsage XML schema θεωρείται αποδεκτό από το Mid office. Το μήνυμα εισάγεται στην ουρά μηνυμάτων προς επεξεργασία και δημιουργείται απάντηση αποδοχής του μηνύματος. Η απάντηση θα περιέχει τουλάχιστον την ημερομηνία λήψης του μηνύματος, την ημερομηνία αποστολής της απάντησης και το όνομα του χρήστη που έστειλε το αρχικό μήνυμα καθώς και κάποιο πεδίο που θα έχει το κατάλληλο status αποδοχής του μηνύματος.

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

Μετά την εισαγωγή του μηνύματος στην ουρά των μηνυμάτων ακολουθεί η πλήρης επεξεργασία του μηνύματος. Αυτή θα πρέπει να γίνεται από ξεχωριστή διεργασία / thread η οποία δε θα πρέπει να κάνει polling στην ουρά των μηνυμάτων αλλά να ενεργοποιείται όταν υπάρχουν μηνύματα στην ουρά. Δηλαδή, η διεργασία χειρισμού των μηνυμάτων θα είναι ανενεργή όταν δεν υπάρχουν μηνύματα στην ουρά. Όταν εισαχθεί κάποιο μήνυμα στην ουρά η εν λόγω διεργασία θα ενεργοποιείται και θα διαβάζει τα μηνύματα της ουράς μέχρι εκείνη να αδειάσει, οπότε και θα απενεργοποιηθεί ξανά.


Έργο ΑΝΝΑ

Η διεργασία ανάγνωσης μηνυμάτων από την ουρά εσφαλμένων μηνυμάτων απλώς θα εξάγει το κάθε μήνυμα από την ουρά και θα το εισάγει μαζί με την απάντηση που στάλθηκε στο File Storage με κατάλληλο metadata για την εύκολη αναζήτηση του εν λόγω μηνύματος.

Η διεργασία ανάγνωσης μηνυμάτων από την ουρά και περεταίρω επεξεργασία τους θα αφαιρεί τα μηνύματα από την ουρά και, αφού τα κάνει parse θα εισάγει τις πληροφορίες που περιέχουν στη βάση δεδομένων του Mid Office. Επίσης τα μηνύματα θα εισάγονται στο File Storage με κατάλληλο metadata για εύκολη αναζήτηση. Θα πρέπει να παρέχονται οι δυνατότητες update μηνυμάτων, διατήρησης ιστορικού αλλαγών καθώς και ορθής διαχείρισης περιπτώσεων μηνυμάτων που δύναται να έρθουν σε λάθος σειρά από το Front Office.

Αφού τελειώσει το parse ακολουθεί η επικοινωνία με τους άλλους Φορείς και η διάχυση των πληροφοριών στα δικά τους πληροφοριακά συστήματα μέσω των Back ends. Η επικοινωνία με κάθε ένα Φορέα θα πρέπει να γίνεται ταυτόχρονα και όχι σειριακά. Η συγκεκριμένη επικοινωνία πρέπει να είναι παράλληλη διότι από τη μία τα αποτελέσματα της είναι τελείως ανεξάρτητα το ένα από το άλλο και από την άλλη θα πρέπει να μην εξαρτάται η επικοινωνία με κάποιον φορέα από τυχόν αστοχία επικοινωνίας με άλλον φορέα.

Το αποτέλεσμα της επικοινωνίας με τους Φορείς θα εγγράφεται ξεχωριστά στη βάση δεδομένων για κάθε Back end. Σε περίπτωση σφάλματος κατά την επικοινωνία με τους άλλους Φορείς μέσω των Back end θα ακολουθούνται οι ενέργειες που περιγράφονται στην αντίστοιχη ενότητα.

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

6.4. Απαιτήσεις για εξασφάλιση αδιάκοπης λειτουργίας

Για όλα τα components του Mid office πρέπει να διασφαλίζεται η εφεδρικότητά τους σε περίπτωση δυσλειτουργίας και μάλιστα στη λύση που θα προτείνει ο ανάδοχος θα πρέπει να επιτρέπει τη μετάπτωση από το ένα component στο εφεδρικό του σε χρόνο μικρότερο των 15 λεπτών και με διαδικασία που θα περιγράφεται αναλυτικά από τον ανάδοχο. Επιπρόσθετα, κατά τη φάση δοκιμών θα πρέπει να δημιουργηθεί σενάριο καταστροφής για όλα τα components, με αντίστοιχη επάνοδο τους σε λειτουργία το οποίο θα επιδειχθεί στην ΕΠΕ. Το ανωτέρω σενάριο θα πρέπει να ενταχθεί και στο σχεδιασμό επαναφοράς του συστήματος.

Προκειμένου να εξασφαλιστεί η υψηλή διαθεσιμότητα του συστήματος, απαιτείται από τον Ανάδοχο η παροχή ενός συστήματος disaster recovery. Το εν λόγω σύστημα θα πρέπει να έχει τις ίδιες δυνατότητες επεξεργασίας και διαχείρισης με το κυρίως σύστημα, αλλά θα έχει μικρότερο αριθμό μονάδων επεξεργασίας και αποθήκευσης. Ο χώρος εγκατάστασης του εφεδρικού συστήματος μπορεί να είναι διαφορετικός από αυτόν του βασικού και θα καθοριστεί κατά το στάδιο της μελέτης εφαρμογής. Ο εξοπλισμός disaster recovery περιγράφεται αναλυτικά στους πίνακες του ΚΕΦΑΛΑΙΟ 10: .

6.5. Backup


Έργο ΑΝΝΑ

Είναι απαραίτητο να εκτελείται backup όλων των τμημάτων του επιπέδου αποθήκευσης. Το backup θα πρέπει να γίνεται αυτόματα τουλάχιστον μία φορά κάθε μέρα. Σε περίπτωση αποτυχίας του backup θα πρέπει άμεσα να ειδοποιούνται οι διαχειριστές του συστήματος και να εμφανίζεται μόνιμο alert στο περιβάλλον διαχείρισης μέχρι να ολοκληρωθεί επιτυχημένα το backup. Από το περιβάλλον διαχείρισης θα πρέπει να μπορεί να ρυθμιστούν οι ώρες που θα γίνεται το backup καθώς και το που θα αποθηκεύεται το αποτέλεσμα του backup. Ομοίως το restore πρέπει να μπορεί να γίνει και μέσω του περιβάλλοντος διαχείρισης αλλά και με τον τρόπο που προτείνει το κάθε component, ενώ ο ανάδοχος θα πρέπει να παραδώσει αναλυτικό εγχειρίδιο backup και restore και θα επιδείξει στην αρμόδια Υπηρεσία του Λ.Σ.-ΕΛ. ΑΚΤ. κατά την περίοδο των δοκιμών τη διαδικασία τόσο του backup όσο και του restore καθώς και τη σωστή λειτουργία του συστήματος μετά το restore.

Ο εξοπλισμός λήψης αντιγράφων ασφαλείας περιγράφεται αναλυτικά στους πίνακες του ΚΕΦΑΛΑΙΟ 10: . Ο εν λόγω εξοπλισμός θα πρέπει να συνοδεύεται από το λογισμικό διαχείρισης, το οποίο θα αποτελεί και τμήμα του διαχειριστικού περιβάλλοντος της ενιαίας ναυτιλιακής θυρίδας, καθώς και από τις απαραίτητες άδειες χρήσης. Μέσω του λογισμικού διαχείρισης θα πρέπει να καθίσταται δυνατή η ρύθμιση της συχνότητας λήψης αντιγράφων, καθώς και η μορφή των μηνυμάτων που θα αποστέλλονται στους διαχειριστές του συστήματος.

6.6. Έλεγχοι Μηνυμάτων

Ο έλεγχος των μηνυμάτων που φθάνουν στο Mid office γίνεται κυρίως μέσω ενός αρχείου XML Schema με το οποίο θα πρέπει να συμφωνούν όλα τα μηνύματα που εισάγονται στην ουρά των μηνυμάτων προς επεξεργασία. Στο εν λόγω XML Schema ορίζονται τόσο οι τύποι των μηνυμάτων όσο και τα δεδομένα που αυτά περιέχουν. Τυχόν έλεγχοι που δεν υλοποιούνται με το XML Schema θα υλοποιηθούν από τον ανάδοχο έχοντας ως στόχο την όσο το δυνατόν μικρότερη καθυστέρηση κατά την απάντηση στο reporting party και την εισαγωγή του εισερχόμενου μηνύματος στην ουρά των μηνυμάτων προς επεξεργασία.

Ο έλεγχος μηνυμάτων θα πρέπει να ενσωματώνει και του ελέγχους που απαιτούνται από τους επιμέρους Φορείς (Back office) έτσι ώστε αν ένα μήνυμα περάσει το συγκεκριμένο έλεγχο να μπορεί να παραδοθεί με κατάλληλη μορφή σε όλα τα Back ends. Σε περίπτωση που υπάρχει κάποια ασυμφωνία μεταξύ των ελέγχων που γίνεται από το Mid office και κάποιον Φορέα ο αποστολέας του αρχικού μηνύματος ήδη θα έχει παραλάβει απάντηση ότι το μήνυμα του είναι αποδεκτό οπότε το πρόβλημα θα πρέπει να επιλυθεί από τους διαχειριστές του συστήματος με τη διαδικασία που περιγράφεται στην παράγραφο «Χειρισμός λαθών».

Θα πρέπει να δίνεται η δυνατότητα στους διαχειριστές του συστήματος για εισαγωγή νέας έκδοσης του XML schema ελέγχων με κατάλληλο metadata για τα στοιχεία αυτού.

6.7. Back ends

Η επικοινωνία με τα πληροφοριακά συστήματα των Φορέων θα πρέπει να γίνεται μέσω μιας σειράς από βιβλιοθήκες τις οποίες ονομάζουμε Back ends και τα οποία ουσιαστικά αποτελούν το Back office της ενιαίας ναυτιλιακής θυρίδας. Τα Back ends πρέπει


Έργο ΑΝΝΑ

να ακολουθούν μια αρθρωτή (modular) αρχιτεκτονική η οποία να επιτρεπτή την on-the-fly αλλαγή τους (δηλαδή ενώ λειτουργεί ο Application server του Mid Office)

να είναι ανεξάρτητα μεταξύ τους

να είναι εύκολα επεκτάσιμα

να είναι εύκολη η υλοποίηση νέων

6.7.1. Υλοποίηση των back ends

Το κάθε backend ουσιαστικά θα πρέπει να υλοποιεί μια διεπαφή για την αποστολή του μηνύματος η οποία και θα εκτελείται από ξεχωριστή διεργασία / thread για κάθε Backend μέσω της οποίας θα γίνεται η διάχυση της πληροφορίας στους Φορείς.

Ο ανάδοχος οφείλει να υλοποιήσει κατάλληλο API για τα backends που θα παρέχει την πρόσβαση στις πληροφορίες του εισερχόμενου μηνύματος (message) καθώς και για τη δημιουργία των αποστελλόμενων μηνυμάτων στους Φορείς σε διάφορες μορφές. Ο ανάδοχος οφείλει να υλοποιήσει πέραν των backends για την επικοινωνία με τους Φορείς που θα περιγραφούν στην αντίστοιχη ενότητα, ένα generic back end για την αποστολή των πληροφοριών σε συγκεκριμένες διευθύνσεις email, ένα generic back end για το ανέβασμα του αρχείου σε SFTP server, ένα generic backend για την κλήση SOAP web service και ένα generic backend για την εισαγωγή στοιχείων σε εξωτερική βάση δεδομένων και να τα παραδώσει μαζί με τον πλήρη και ορθά σχολιασμένο κώδικα τους καθώς και να επιδείξει τον πλήρη κύκλο υλοποίησης και εγκατάστασης ενός backend.

Το κάθε backend οφείλει επίσης να προσφέρει κατάλληλο API για τη διαχείριση των παραμέτρων του. Ενδεικτικά αναφέρονται: Σε ποια email θα στέλνονται τα μηνύματα, ποιο θα είναι το endpoint και τα credetials του web service που θα καλείται, σε ποιο ftp server θα γίνεται το upload των μηνυμάτων κοκ. Οι παράμετροι αυτές είναι αυθαίρετες ανά backend και ορίζονται από την υλοποίηση του κάθε backend.

Το API του backend θα έχει δύο ακόμα μεθόδους προς υλοποίηση: Μια μέθοδο που θα επιστρέφει την κατάσταση του backend για monitoring και μια μέθοδο που θα επιστρέφει το μήνυμα προς αποστολή στο Φορέα για το χειρισμό των σφαλμάτων. Η πρώτη μέθοδος θα πρέπει να εξετάζει ότι το backend θα λειτουργήσει σωστά και η δεύτερη μέθοδος επιστρέφει το μήνυμα που θα σταλθεί στο Φορέα ώστε να μπορούν οι διαχειριστές να εξετάσουν τα δεδομένα που πρόκειται να αποσταλούν.

Τέλος, η συμπεριφορά του backend πρέπει να είναι configurable μέσω παραμέτρων όταν συμβούν λάθη επικοινωνίας, όπως αναλύεται και στην ενότητα “Χειρισμος λαθών”. Δηλαδή για κάθε backend θα καθορίζεται πόσες φορές πρέπει να γίνει προσπάθεια για επαναποστολή του μηνύματος μετά από κάποιο σφάλμα επικοινωνίας (ίσως και καμία) καθώς και του χρόνου που θα πρέπει να περιμένει το Mid office μεταξύ των προσπαθειών.

6.7.2. Διαχείριση των backends

Η εισαγωγή / ενεργοποίηση νέων backends καθώς και η απενεργοποίηση υφιστάμενων θα πρέπει να γίνεται μέσα από το περιβάλλον διαχείρισης της ενιαίας ναυτιλιακής θυρίδας. Κάθε backend θα έχει ένα μοναδικό κλειδί ώστε να μπορεί να καθοριστεί αν κάποιο backend που ανεβάζει ο διαχειριστής είναι νέο backend ή πρέπει να αντικαταστήσει ένα υπάρχον. Ο διαχειριστής θα πρέπει να μπορεί να απενεργοποιήσει και να ενεργοποιήσει


Έργο ΑΝΝΑ

κατά βούληση κάθε ένα backend καθώς και να αλλάξει τις ιδιότητες του, ενώ όλες του οι ενέργειες αυτές θα πρέπει να καταγράφονται (auditing).

6.8. Χειρισμός Λαθών

Το σύστημα πρέπει να μπορεί να διαχειριστεί σωστά τυχόν λάθη που μπορεί να συμβούν. Αυτά τα λάθη κυρίως αφορούν την επικοινωνία με τους άλλους Φορείς. Έναν non-valid μήνυμα δεν αποτελεί λάθος, αλλά αποτελεί μέρος της κανονικής ροής και σε αυτή την περίπτωση απλώς θα επιστρέψει ένα μήνυμα λάθους στο reporting party.

Αντίθετα, τα λάθη αφορούν την επικοινωνία με τα Back ends και μπορεί να είναι δύο ειδών:

Λάθη επικοινωνίας: Δεν είναι δυνατή η επικοινωνία με το Back end, το Back end δεν συμπεριφέρεται σωστά κοκ

Λάθη εφαρμογής: Για κάποιους λόγους τα δεδομένα τα οποία έγιναν αποδεκτά (άρα πέρασαν από τους ελέγχους του Mid office με το XML Schema) δεν γίνονται αποδεκτά από το Back end. Αυτό οφείλεται συνήθως στο ότι πλέον οι έλεγχοι που γίνονται στο Mid office έχουν αποσυγχρονιστεί από τους ελέγχους κάποιου Back end.

Σε περίπτωση λοιπόν σφάλματος εφαρμογής θα γίνεται εκκίνηση ροής εργασίας (workflow) για το χειρισμό των σφαλμάτων όπως εξηγείται στην αντίστοιχη παράγραφο.

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

6.9. Ροή εργασίας χειρισμού σφαλμάτων

Ο σκοπός αυτής της ροής είναι να φθάσει τελικά το μήνυμα στο Φορέα. Όταν δηλαδή συμβεί κάποιο σφάλμα εφαρμογής ή αποτύχουν όλες επαναλήψεις επικοινωνίας σε περίπτωση σφάλματος επικοινωνίας, θα δημιουργείται ειδικό alert στο περιβάλλον διαχείρισης μέσω του οποίου οι διαχειριστές θα βλέπουν τις πληροφορίες για το εν λόγω σφάλμα. Θα τους δίνεται η δυνατότητα είτε να δοκιμάσουν ξανά την αποστολή του μηνύματος (άρα θα έχουν διορθωθεί τα προβλήματα) είτε να το διαχειριστούν εξωσυστημικά. Σε όλες τις περιπτώσεις πρέπει να είναι ξεκάθαρο το ιστορικό του μηνύματος.

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


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 7: Πιλοτικό έργο 3 - Back Office

7.1. Γενικά

Το παρόν πιλοτικό έργο συνίσταται στην υλοποίηση του back οffice της ενιαίας ναυτιλιακής θυρίδας που θα υλοποιηθεί, ήτοι στη διασύνδεσή της με τα πληροφοριακά συστήματα των έτερων συναρμόδιων φορέων της ελληνικής διοίκησης και συγκεκριμένα με:

• το ICISnet των τελωνειακών υπηρεσιών

• το SiS του ΥΠτΠ

• το πληροφοριακό σύστημα του έργου SHIPSAN για την αποστολή σε αυτό του δηλωτικού υγείας και άλλων υγειονομικών πληροφοριών

• την κεντρική υποδομή του SafeSeaNet του EMSA, με την οποία θα ανταλάσσονται τα στοιχεία του SafeSeaNet, σύμφωνα με τις σχετικές απαιτήσεις του EMSA στην οποία θα πρέπει να αποστέλλονται τα μηνύματα που προβλέπονται από τις αντίστοιχες κοινοτικές οδηγίες κλπ.

Για κάθε ένα εκ των παραπάνω λοιπόν ο ανάδοχος οφείλει να υλοποιήσει ξεχωριστό back end όπως αυτά περιγράφηκαν στο προηγούμενο κεφάλαιο.

Για τις ανάγκες του έργου θα χρησιμοποιηθούν οι δικτυακές υποδομές του ΣΥΖΕΥΞΙΣ. Στο πιλοτικό έργο αυτό θα πρέπει να αναπτυχθούν οι σχετικές διεπαφές ώστε να γίνεται προώθηση των αντίστοιχων μηνυμάτων σε άλλους Φορείς για την επίτευξη της απαιτουμενης διασύνδεσης. Επιπρόσθετα, σε συνεργασία με τα άλλα Υπουργεία ο Ανάδοχος θα πρέπει να εκτελέσει όλες τις απαιτούμενες ενέργειες για την ασφαλή μεταφορά δεδομένων βάσει των τεχνικών λύσεων που θα προσδιορισθούν στη μελέτη εφαρμογής τόσο του κάθε πιλοτικού όσο και του συνολικού έργου. Για το σχεδιασμό των διεπαφών εκτός των στοιχείων που θα παρασχεθούν από το Φορέα μας ο Ανάδοχος θα δύναται να προχωρά σε απευθείας επαφή με τους άλλους Φορείς για την αναζήτηση των απαραίτητων στοιχείων για το σχεδιασμό των διεπαφών και τη δικτυακή σύνδεση των εφαρμογών. Στις εν λόγω διασυνδέσεις δε θα πρέπει να υφίσταται κανένας περιορισμός επεκτασιμότητας του συστήματος.

7.2. Διασύνδεση με το σύστημα ICISNet

7.2.1. Περιγραφή

Όπως αναφέρθηκε και στην παράγραφο 1.4.1 του παρόντος, το σύστημα ICISnet είναι το Πληροφοριακό Σύστημα των Τελωνείων και υποστηρίζει τη λειτουργία της Τελωνειακής Υπηρεσίας, με χρήση κεντρικοποιημένων λειτουργιών και υπηρεσιών που προσφέρονται ηλεκτρονικά στους συναλλασσόμενους.

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


Έργο ΑΝΝΑ

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

7.2.2. Απαιτούμενα στοιχεία για τη διασύνδεση

Προκειμένου να επιτευχτεί η εν λόγω διασύνδεση, στον ανάδοχο θα παρασχεθούν από το ΛΣ-ΕΛ.ΑΚΤ, σε συνεργασία με τις τελωνειακές αρχές, τα παρακάτω στοιχεία:

• Το μοντέλο δεδομένων (data model) που χρησιμοποιείται από το σύστημα ICISnet

• Διάγραμμα UML των κλάσεων και τις αντίστοιχες δομές που χρησιμοποιούνται από το σύστημα

• Διεπαφές προγραμματισμού εφαρμογών (APIs) του συστήματος

• Τα σχετικά τελικά σημεία (end points) για εισαγωγή/εξαγωγή δεδομένων στο ICISnet

• Τα σημεία φυσικής διασύνδεσης του συστήματος, συμπεριλαμβανομένων διευθύνσεων IP και υποδομών δικτύου

• Τα πιστοποιητικά (credentials) που απαιτούνται για τη σύνδεση με αυτό.

7.2.3. Μελέτη εφαρμογής

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

Για τις ανάγκες της διασύνδεσης θα χρησιμοποιηθούν οι δικτυακές υποδομές του ΣΥΖΕΥΞΙΣ. Σε περίπτωση που από τη μελέτη εφαρμογής προκύψει η ανάγκη προμήθειας περαιτέρω εξοπλισμού, αυτή βαραίνει τον ανάδοχο.

Η διασύνδεση που θα προκύψει, δεν θα θέτει κανένα περιορισμό στην επεκτασιμότητα του συστήματος, όπως θα τεκμηριώνεται στη μελέτη εφαρμογής.

7.2.4. Δικαίωμα προαίρεσης

Επισημαίνεται ότι, όπως αναλύεται στην παράγραφο 11.12, η περιγραφόμενη στην παρούσα παράγραφο υλοποίηση της διασύνδεσης της ενιαίας ναυτιλιακής θυρίδας με το σύστημα ICISnet θα πραγματοποιηθεί μόνον εφόσον ασκηθεί το αντίστοιχο δικαίωμα προαίρεσης από το ΛΣ-ΕΛ.ΑΚΤ. Η εκπόνηση από τον Ανάδοχο της μελέτης εφαρμογής για την εν λόγω διασύνδεση είναι υποχρεωτική και δεν σχετίζεται με την άσκηση ή όχι του δικαιώματος προαίρεσης από το ΛΣ-ΕΛ.ΑΚΤ.

7.3. Διασύνδεση με το σύστημα SiS


Σύμφωνα και με τα αναφερόμενα στην παράγραφο 1.4.3 του παρόντος, το Σύστημα Πληροφοριών Schengen (Schengen Information System) – S.I.S. είναι ένα κοινό ηλεκτρονικό αρχείο δεδομένων, το οποίο, βάσει συγκεκριμένων άρθρων της Συνθήκης, τα κράτη μέλη τροφοδοτούν με πληροφορίες. Συγκεντρώνει δύο μεγάλες κατηγορίες πληροφοριών. Η


Έργο ΑΝΝΑ

πρώτη αφορά αναζητούμενα πρόσωπα (διωκόμενοι, εξαφανισμένοι ενήλικες και ανήλικοι κ.λπ.). Η δεύτερη αφορά αναζητούμενα οχήματα ή αντικείμενα, όπως έγγραφα ταυτότητας, άδειες κυκλοφορίας οχημάτων και πινακίδες αριθμού κυκλοφορίας που έχουν κλαπεί ή απολεσθεί. Σε εθνικό επίπεδο την ευθύνη της εύρυθμης λειτουργίας του S.I.S. έχει το 3ο Τμήμα Τεχνικής Υποστήριξης N.S.I.S. της Διεύθυνσης Πληροφορικής του Αρχηγείου της Ελληνικής Αστυνομίας.

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

7.3.2. Απαιτούμενα στοιχεία για τη διασύνδεση

Προκειμένου να επιτευχτεί η εν λόγω διασύνδεση, στον ανάδοχο θα παρασχεθούν από το ΛΣ-ΕΛ.ΑΚΤ, σε συνεργασία με την ΕΛ.ΑΣ., τα παρακάτω στοιχεία:

• Το μοντέλο δεδομένων (data model) που χρησιμοποιείται από το σύστημα SiS II

• Διάγραμμα UML των κλάσεων και τις αντίστοιχες δομές που χρησιμοποιούνται από το σύστημα

• Διεπαφές προγραμματισμού εφαρμογών (APIs) του συστήματος

• Τα σχετικά τελικά σημεία (end points) για εισαγωγή/εξαγωγή δεδομένων στο SiS II

• Τα σημεία φυσικής διασύνδεσης των συστημάτων, συμπεριλαμβανομένων διευθύνσεων IP και υποδομών δικτύου

• Τα πιστοποιητικά (credentials) που απαιτούνται για τη σύνδεση με αυτό.


Στη μελέτη εφαρμογής θα καθοριστούν οι λεπτομερείς απαιτήσεις για την επίτευξη της διασύνδεσης, όπου θα συμπεριλαμβάνουν και τα ακριβή μηνύματα/δεδομένα που θα ανταλλάσσονται. Για το λόγο αυτό, ο ανάδοχος θα έρθει σε απευθείας συνεννόηση και με τη διεύθυνση πληροφορικής της ΕΛ.ΑΣ. Στην περίπτωση που απαιτείται η παροχή στοιχείων πέραν όσων αναφέρονται στην προηγούμενη παράγραφο, αυτά θα καταγραφούν αναλυτικά στη μελέτη εφαρμογής.

Για τις ανάγκες της διασύνδεσης θα χρησιμοποιηθούν οι δικτυακές υποδομές του ΣΥΖΕΥΞΙΣ. Σε περίπτωση που από τη μελέτη εφαρμογής προκύψει η ανάγκη προμήθειας περαιτέρω εξοπλισμού, αυτή βαραίνει τον ανάδοχο.


7.3.4. Δικαίωμα προαίρεσης

Επισημαίνεται ότι, όπως αναλύεται στην παράγραφο 11.12, η περιγραφόμενη στην παρούσα παράγραφο υλοποίηση της διασύνδεσης της ενιαίας ναυτιλιακής θυρίδας με το σύστημα SIS II θα πραγματοποιηθεί μόνον εφόσον ασκηθεί το αντίστοιχο δικαίωμα προαίρεσης από το ΛΣ-ΕΛ.ΑΚΤ. Η εκπόνηση από τον Ανάδοχο της μελέτης εφαρμογής για


Έργο ΑΝΝΑ

την εν λόγω διασύνδεση είναι υποχρεωτική και δεν σχετίζεται με την άσκηση ή όχι του δικαιώματος προαίρεσης από το ΛΣ-ΕΛ.ΑΚΤ.

7.4. Διασύνδεση με το σύστημα SafeSeaNet

7.4.1. Γενικά

Στο παρόν πιλοτικό έργο, η υπό ανάπτυξη ενιαία ναυτιλιακή θυρίδα θα διασυνδεθεί και θα ανταλλάσσει μηνύματα απευθείας με το ευρωπαϊκό σύστημα SafeSeaNet που λειτουργεί στις εγκαταστάσεις του EMSA στην Λισσαβόνα, χωρίς μεσολάβηση άλλης εθνικής εφαρμογής SafeSeaNet.

Το SafeSeaNet (SSN) αποτελεί το κοινοτικό σύστημα ανταλλαγής ναυτιλιακών πληροφοριών, το οποίο έχει αναπτυχθεί από την Ευρωπαϊκή Επιτροπή σε συνεργασία με τα Κράτη-Μέλη για την εξασφάλιση της εφαρμογής της κοινοτικής νομοθεσίας, για την ενίσχυση της ασφάλειας στη θάλασσα και της ασφάλειας λιμένων, την προστασία θαλασσίου περιβάλλοντος καθώς και την αποτελεσματικότητα στη θαλάσσια κυκλοφορία και τις θαλάσσιες μεταφορές.

Όλες οι πληροφορίες που συλλέγονται από τα εθνικά συστήματα αποθηκεύονται τοπικά με τρόπο ώστε να είναι διαθέσιμες για αποστολή τους στα άλλα Κ-Μ εφόσον ζητηθεί. Το κεντρικό σύστημα (SSN Core) λειτουργεί αφ’ ενός ως ευρετήριο (Yellow Pages) για τις πληροφορίες που τηρούνται από τα Κ-Μ και αφ’ ετέρου ως ο διαμεσολαβητής (Hub & Spoke) για την ανταλλαγή των πληροφοριών μεταξύ των Κ-Μ. Στις περιπτώσεις αποθήκευσης νέων ή τροποποίησης υφισταμένων πληροφοριών, τα εθνικά συστήματα αποστέλλουν ένα σχετικό μήνυμα (notification message) στο κεντρικό σύστημα της Ε.Ε. ώστε να γνωστοποιηθεί το είδος και η διαθεσιμότητα των πληροφοριών. Η γενική αρχιτεκτονική του συστήματος απεικονίζεται στο Σχήμα 7.1 .

Σχήμα 7.1 Γενική αρχιτεκτονική του συστήματος SSN


Έργο ΑΝΝΑ

7.4.2. Βασικές Υποχρεώσεις των Κρατών Μελών

Οι βασικές υποχρεώσεις των Κρατών Μελών στο πλαίσιο του έργου είναι οι εξής:

• συλλογή των απαιτούμενων πληροφοριών και την αυτόματη αποστολή στο κεντρικό σύστημα της Ε.Ε. μιας ανακοίνωσης (ηλεκτρονικό μήνυμα) σχετικά με το είδος και τη διαθεσιμότητα των πληροφοριών αυτών.

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

• δυνατότητα του συστήματος να υποβάλλει σχετικές αιτήσεις για λήψη πληροφοριών από άλλα Κ-Μ μέσω του κεντρικού συστήματος (requests)

• διαθεσιμότητα των πληροφοριών σε 24ωρη βάση

• πολιτική αποθήκευσης και διατήρησης των δεδομένων του συστήματος σύμφωνα με το έγγραφο IFCD (interface and functionalities control document).

7.4.3. Ανταλλασσόμενες πληροφορίες μεταξύ των Κρατών Μελών και μέθοδοι συλλογής τους από τις Αρμόδιες Αρχές

Οι ανταλλασσόμενες, μέσω του συστήματος, πληροφορίες βασίζονται στις αναφορές που υποβάλλονται στις Αρμόδιες Αρχές από τους πλοιοκτήτες/εφοπλιστές, διαχειριστές, πλοιάρχους και πράκτορες των πλοίων σε εφαρμογή των Κοινοτικών Οδηγιών 2002/59, 2000/59 και 2009/16, όπως έχουν ενσωματωθεί στο εθνικό δίκαιο, καθώς και του Κανονισμού 725/2004. Οι αναφορές αυτές, οι οποίες ανταλλάσσονται μέσω μηνυμάτων XML είναι:

Port Plus Notifications: Αφορά τις πληροφορίες που περιλαμβάνονται στις αναγγελίες των πλοίων, οι οποίες υποβάλλονται στις κατά τόπους Λιμενικές Αρχές, προκειμένου να ενημερώνουν το σύστημα με πληροφορίες αναφορικά με τον 72 ωρών προ-κατάπλου σε κοινοτικό λιμένα για τα υπόχρεα σε εκτεταμένη PSC επιθεώρηση πλοία, με τον 24 ωρών προ-κατάπλου, τον ακριβή αριθμό επιβαινόντων, την ακριβή ώρα κατάπλου και απόπλου και αναφορών μεταφοράς επικίνδυνων/ρυπογόνων φορτίων (HAZMAT Notifications).

Ship Notifications: Χρησιμοποιείται για να ενημερώσει το SafeSeaNet σχετικά με τη θέση, την ταυτότητα του πλοίου, το ταξίδι και πληροφορίες για το φορτίο του. Αυτές οι αναφορές ουσιαστικά βασίζονται ή στα μηνύματα MRS (Mandatory Reporting Systems), ή στα μηνύματα AIS (Automatic Identification Systems), ή και στα δυο.

Security Notifications: Σύμφωνα με το άρθρο (11), παράγραφοι (1) και (2) του Νόμου 3622/2007 (ΦΕΚ 281 Α) και τα άρθρα (6) και (7) του Κανονισμού (ΕΚ) 725/2004, όταν ένα πλοίο, που υπάγεται στο πεδίο εφαρμογής τους σκοπεύει να εισέλθει σε λιμένα της Επικράτειας απαιτείται προηγούμενα ο πλοίαρχός του να υποβάλλει στην τοπική Λιμενική Αρχή τις πληροφορίες που προβλέπονται στον κανόνα (9), παράγραφος (2) του Κεφαλαίου ΧΙ-2 της Δ.Σ. SOLAS. Τα μηνύματα αυτά θα ενημερώνουν το SafeSeaNet ότι ο αποστολέας διαθέτει κάποιες πληροφορίες ασφαλείας σχετικά με ένα συγκεκριμένο σκάφος.

Alert Notifications (Incident Reports): Μέσω των μηνυμάτων της κατηγορίας αυτής, ανταλλάσσονται πληροφορίες που διαθέτουν οι Αρμόδιες Αρχές των Κ-Μ για στοιχεία όπως:


Έργο ΑΝΝΑ

• πλοία τα οποία - σύμφωνα με την Κ.Ο. 2002/59 όπως τροποποιήθηκε και ισχύει - θεωρείται ότι παρουσιάζουν δυνητικό κίνδυνο για τη ναυσιπλοΐα ή ότι συνιστούν απειλή για την ασφάλεια στη θάλασσα, την ασφάλεια των προσώπων ή το περιβάλλον

• θαλάσσια συμβάντα και ατυχήματα σύμφωνα με την Κ.Ο. 2002/59 όπως τροποποιήθηκε και ισχύει

• αποτελέσματα επιθεωρήσεων ή εξακριβώσεων που έγιναν είτε με πρωτοβουλία των Κ-Μ είτε κατ' αίτηση άλλου Κ-Μ.

Στο πλαίσιο του SafeSeaNet Group έχουν καθοριστεί πρότυπα σχετικών προειδοποιητικών μηνυμάτων, τα οποία ανταλλάσσονται σύμφωνα με τις Οδηγίες Ανταλλαγής που καθορίζονται στο τεχνικό/επιχειρησιακό εγχειρίδιο “SafeSeaNet Incident Reports Messages Guidelines”) (Παράρτημα VI).

Ειδικά για τα Waste reports, πρόκειται για πληροφορίες σχετικές με τύπους και ποσότητες αποβλήτων και καταλοίπων προς παράδοση ή και προς παραμονή επί του πλοίου σύμφωνα με τα προβλεπόμενα από την Κ.Ο. 2000/59 (όπως τροποποιήθηκε με την Κ.Ο. 2007/71 και ενσωματώθηκε στην εθνική νομοθεσία με την ΚΥΑ 8111.1/41/2009 ΦΕΚ 412 Β).

Οι τεχνικές απαιτήσεις των μηνυμάτων των παραπάνω αναφορών βρίσκονται αναλυτικά στο Παράρτημα V (XML Messaging Reference Guide) όπως αυτό θα ισχύει και θα έχει διαμορφώνεται κατά τη διάρκεια ισχύος της σύμβασης, δεδομένου ότι αποτελεί ένα δυναμικό έγγραφο.

7.4.4. Βασικές Λειτουργικές Δυνατότητες

Για την επίτευξη των ανωτέρω στόχων το σύστημα θα υποστηρίζει όλες τις λειτουργικές δυνατότητες των πληροφοριών που δύναται να ανταλλάσσονται μεταξύ του εθνικού συστήματος και της Ευρωπαϊκής εφαρμογής ή συστημάτων άλλων Κρατών-Μελών, όπως αυτές καθορίζονται και περιγράφονται στο Παράρτημα V (XML Messaging Reference Guide). Το σύστημα που θα δημιουργηθεί θα πρέπει να έχει τη δυνατότητα αποστολής και λήψης όλων των τύπων μηνυμάτων και πληροφοριών (“send και get notifications”) που περιγράφονται στο προαναφερόμενο Παράρτημα V και σύμφωνα με τους επιχειρησιακούς οδηγούς των λοιπών τεχνικών/επιχειρησιακών οδηγών του EMSA, όπως το Παράρτημα VI αναφορικά με τα Incident Reports. Τόσο οι τεχνικοί οδηγοί όσο και οι επιχειρησιακοί οδηγοί για την εξέλιξη και λειτουργία του SafeSeaNet αποτελούν δυναμικά έγγραφα τα οποία διαμορφώνονται από τα Κράτη-Μέλη και τον EMSA και ως εκ τούτου το σύστημα θα πρέπει να είναι επικαιροποιημένο με τις πιο πρόσφατες εκδόσεις των αναφερόμενων προσαρτημάτων του παρόντος. Οι ακριβείς λειτουργικές δυνατότητες του συστήματος θα καθοριστούν σε συνεργασία με τις αρμόδιες Υπηρεσίες ΛΣ-ΕΛ.ΑΚΤ κατά την φάση ανάλυσης απαιτήσεων του συστήματος. Επιπρόσθετα, και όσον αφορά τη ροή εργασιών, πρέπει να ικανοποιούνται οι περιορισμοί που περιγράφονται στην τρέχουσα έκδοση του εγγράφου Member State Commissioning Test Plan, το οποίο είναι προσβάσιμο στον ιστότοπο του EMSA (http://www.emsa.europa.eu/documents/technical-documentation.html).

7.4.5. Μηχανισμός ανταλλαγής μηνυμάτων θαλασσίων συμβάντων


Έργο ΑΝΝΑ

Το σύστημα θα παρέχει πλήρη Διαχείριση (εισαγωγή, αποστολή, λήψη, ενημέρωση, αναζήτηση, παρουσίαση) των μηνυμάτων που ανταλλάσσονται μεταξύ των αρμοδίων Αρχών των Κ-Μ της Ε.Ε. (Alert Messages – Incident Reports, Παράρτημα VI) σχετικά με πληροφορίες των Κ-Μ που προβλέπονται από τα άρθρα 16 και 17 της Κοινοτικής Οδηγίας 2002/59 όπως τροποποιήθηκε και ισχύει και όπως αυτά καθορίζονται από τα αρμόδια όργανα της Ε.Ε. (SafeSeaNet Group).

Στο πλαίσιο του συστήματος θα αναπτυχθούν τα πρότυπα μηνύματα (Alert Messages - Incident Reports ) όπως έχουν καθορισθεί από τα αρμόδια όργανα της Ε.Ε. σύμφωνα με το τεκμηριωτικό υλικό του Παραρτήματος VI.

Σαν εναλλακτική (backup) επιλογή για τον χρήστη, θα εξακολουθεί να ισχύει η δυνατότητα της απ’ ευθείας καταχώρησης των πληροφοριών είτε της ηλεκτρονικής αποστολής αρχείων κειμένου, τα οποία περιέχουν τις σχετικές πληροφορίες στο κεντρικό σύστημα της Ε.Ε., η πρόσβαση στο οποίο γίνεται με τη χρήση web browser.

7.4.6. Πραγματοποίηση δοκιμών

Ο Ανάδοχος υποχρεούται στην πραγματοποίηση των απαιτούμενων δοκιμών επικοινωνίας και ανταλλαγής πληροφοριών με το αντίστοιχο σύστημα της Ε.Ε. προκειμένου να διαπιστωθεί η συμμόρφωση του συστήματος με τις απαιτήσεις του σχετικού προτύπου και η συμβατότητα των δύο συστημάτων. Οι δοκιμές θα πραγματοποιηθούν από στελέχη του Αναδόχου και του Φορέα σύμφωνα με τα προβλεπόμενα στο προαναφερθέν Member State Commissioning Test Plan και θα επαναληφθούν όσες φορές απαιτηθεί, μέχρι να ολοκληρωθούν με επιτυχία, η οποία θα πιστοποιηθεί από τη σχετική ηλεκτρονική αλληλογραφία με την αρμόδια Υπηρεσία της Ε.Ε. Η σύνταξη των σχετικών εγγράφων (περιγραφή σεναρίων δοκιμών, αναφορές, κλπ.) αποτελεί υποχρέωση του Αναδόχου και θα πραγματοποιηθεί σε συνεργασία με τους υπευθύνους του Φορέα και το τμήμα τεχνικής υποστήριξης (helpdesk) του κεντρικού συστήματος της Ε.Ε..

7.4.7. Δίκτυο SafeSeaNet

Το ΥΝΑ/Α/ΛΣ-ΕΛ.ΑΚΤ. είναι συνδεδεμένο στο εθνικό δίκτυο ‘ΣΥΖΕΥΞΙΣ’ μέσω του οποίου είναι εφικτή η πρόσβαση τόσο στο διαδίκτυο (Internet) όσο και στο Ευρωπαϊκό δίκτυο ‘sTESTA’.

Δεδομένου ότι το κεντρικό σύστημα SafeSeaNet διαθέτει επίσης πρόσβαση τόσο στο διαδίκτυο (Internet) όσο και στο Ευρωπαϊκό δίκτυο ‘sTESTA’, για την επικοινωνία των δύο συστημάτων, ως πρωτεύουσα σύνδεση θα χρησιμοποιηθεί η σύνδεση του δικτύου ‘sTESTA’, ενώ η σύνδεση μέσω του διαδικτύου (Internet) θα χρησιμοποιηθεί ως εφεδρική.

Λαμβάνοντας υπόψη ότι για την ανταλλαγή πληροφοριών με το κεντρικό σύστημα της Ε.Ε. απαιτείται κρυπτογράφηση των δεδομένων με τη χρήση του πρωτοκόλλου Secure Socket Layer (SSL) με χρήση πιστοποιητικών και στα δύο συστήματα (two way SSL), τα οποία εκδίδονται σε συνεργασία με την EMSA, κατόπιν αιτήσεως μέσω της Διεύθυνσης Πληροφορικής του ΛΣ-ΕΛ.ΑΚΤ.

Η αυθεντικοποίηση για την πρόσβαση των χρηστών στις λειτουργίες διαχείρισης των πληροφοριών από τις αρμόδιες Αρχές και την ηλεκτρονική υποβολή αναφορών από τους υπόχρεους, θα γίνεται διαμέσου πρωτοκόλλου HTTPS, ενώ παράλληλα απαιτείται


Έργο ΑΝΝΑ

κρυπτογράφηση των δεδομένων με τη χρήση του πρωτοκόλλου Secure Socket Layer (SSL) με χρήση πιστοποιητικού μόνον στο σύστημα του ΥΝΑ/Α/ΛΣ-ΕΛ.ΑΚΤ. (one way SSL).

Οι εξυπηρετητές του υπό προμήθεια συστήματος θα πρέπει να διαθέτουν τα απαιτούμενα ψηφιακά πιστοποιητικά (Digital Certificates), τα οποία υπογράφονται (signed) από τον EMSA, κατόπιν σχετικού αιτήματος που θα πραγματοποιηθεί από την αρμόδια Υπηρεσία του ΛΣ-ΕΛ.ΑΚΤ σε συνεργασία με τον ανάδοχο.

7.5. Διασύνδεση με το σύστημα Shipsan


Όπως περιγράφεται και στην παράγραφο 1.4.4 του παρόντος, το έργο Shipsan συντονίζεται από το Εργαστήριο Υγιεινής και Επιδημιολογίας του Πανεπιστήμιου Θεσσαλίας σε συνεργασία με την Εθνική Σχολή Δημόσιας Υγείας και το Υπουργείο Υγείας. Το πληροφοριακό σύστημα του έργου χρησιμοποιείται για τη μετάδοση της Ναυτιλιακής Δήλωσης Υγείας, της εκτίμησης και αντιμετώπισης κινδύνων, την έκδοση πιστοποιητικών υγείας πλοίων.

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

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


Στη μελέτη εφαρμογής θα καθοριστούν οι λεπτομερείς απαιτήσεις για την επίτευξη της διασύνδεσης, όπου θα συμπεριλαμβάνουν και τα ακριβή μηνύματα/δεδομένα που θα ανταλλάσσονται. Για το λόγο αυτό, ο ανάδοχος θα έρθει σε απευθείας συνεννόηση με τους υπεύθυνους του έργου Shipsan.



Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 8: Πιλοτικό έργο 4 – Διεπαφή ανάκτησης δεδομένων

Το συγκεκριμένο έργο θα παρέχει πρόσβαση στα δεδομένα της ενιαίας ναυτιλιακής θυρίδας μέσω της βάσης δεδομένων του Mid Office σε χρήστες και ομάδες χρηστών δημοσίων οργανισμών (συμπεριλαμβανομένου και του ΛΣ-ΕΛΑΚΤ) μέσω αναφορών (reports) που θα βλέπουν και κατεβάζουν. Η πρόσβαση στα δεδομένα θα πρέπει να είναι μόνο ανάγνωσης.

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

8.1. Γενικά

Το υποσύστημα πρόσβασης στα δεδομένα είναι μια Enterprise Web εφαρμογή αποτελούμενη από τρία ξεχωριστά επίπεδα: Web, Application και Database/Storage. Το επίπεδο Web ουσιαστικά προσφέρει ένα επίπεδο παρουσίασης για τους χρήστες ενώ στο Application Layer υπάρχουν τα domain objects της εφαρμογής και χρησιμοποιείται ως ενδιάμεση πρόσβαση προς το επίπεδο της αποθήκευσης. Για το επίπεδο της βάσης δεδομένων θα χρησιμοποιείται η κεντρική βάση δεδομένων του Mid office, οπότε θα πρέπει να υπάρχει πρόσβαση στον κόμβο του Mid Office.

Η εμφάνιση και η λειτουργικότητα του υποσυστήματος πρόσβασης σε δεδομένα (GUI) πρέπει να είναι παρόμοια και να ακολουθεί τις ίδιες αρχές με αυτές που αναλύονται στην ενότητα για το Front Office. Ο χρήστης δηλαδή βλέποντας το GUI του Front Office και το GUI του συστήματος πρόσβασης στα δεδομένα θα πρέπει να καταλαβαίνει ότι ανήκουν και τα δύο στην ενιαία ναυτιλιακή θυρίδα.

8.2. Ασφάλεια

Είναι απαραίτητο να διασφαλιστεί η ασφάλεια του εν λόγω συστήματος μιας και συνδέεται με την κεντρική βάση της ενιαίας ναυτιλιακής θυρίδας. Προς τούτο, θα πρέπει να επιτρέπονται μόνο συνδέσεις από γνωστά δίκτυα μέσω ασφαλών συνδέσεων (VPN) είτε μέσω του εσωτερικού δικτύου του Α/ΛΣ-ΕΛΑΚΤ.

8.3. Αναφορές

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

Τις αναφορές αυτές θα τις δημιουργούν οι διαχειριστές του συστήματος μέσω γραφικής διεπαφής από όπου και θα μπορούν και θα μπορούν να παραμετροποιήσουν.

• την εμφάνιση των αναφορών, η οποία θα πρέπει να διαμορφώνεται από τους διαχειριστές με τεχνικές “drag n drop” για το που θα εμφανιστεί κάθε στοιχείο της καθώς και προσθήκη τυχόν στατικού κειμένου ή κάποιων κανόνων (πχ


Έργο ΑΝΝΑ

σημερινή ημερομηνία, πλήθος στοιχείων που περιέχει μια συγκεντρωτική αναφορά κλπ)

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

• τους χρήστες ή ομάδες χρηστών που θα έχουν πρόσβαση σε αυτά

• τυχόν επιπλέον κανόνες για την πρόσβαση στα δεδομένα (πχ με ημερομηνία ή γεωγραφικά κριτήρια).

• Φίλτρα που θα βλέπουν οι χρήστες για να κάνουν αναζήτηση στα περιεχόμενα των αναφορών (ελεύθερο κείμενο, drop downs, επιλογή ημερομηνιών)

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

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

Όλες οι αναφορές θα πρέπει να μπορούν να εξάγονται (download) σε αρχεία μορφής odf, doc/xls, docx/xlsx, csv, txt, html, pdf. Πρέπει να υπάρχει πρόβλεψη για κεφαλίδες, υποσέλιδα (headers, footers) καθώς και για κείμενο που θα μπαίνει στην πρώτη και την τελευταία σελίδα (σε περίπτωση που πραγματοποιείται εξαγωγή σε σελιδοποιημένη μορφή -- pdf, doc κλπ).

Πρέπει να δίνεται η δυνατότητα στους διαχειριστές να ορίζουν email ή χρήστες ή ομάδες χρηστών προς τους οποίους θα αποστέλλεται κάποια αναφορά ως attachment σε e-mail. Οι διαχειριστές ορίζουν το κάθε πότε θα αποστέλλεται η αναφορά (πχ κάθε μέρα στις 01.00 ή κάθε Δευτέρα στις 13.00) και σε ποιους. Για την αποστολή θα πρέπει να μπορούν να μπουν κανόνες, πχ στείλε την αναφορά μόνο αν περιέχει πάνω από 10 διαφορετικά πλοία ή αν περιέχει πλοίο συγκεκριμένης σημαίας ή αν περιέχει πλοίο με επικίνδυνα φορτία κλπ. Επίσης θα πρέπει να υπάρχει η δυνατότητα δημιουργίας events μέσω των οποίων θα στέλνονται αναφορές (δηλαδή αν έρθει κάποιο πλοίο με επικίνδυνα φορτία να σταλεί αναφορά με τα στοιχεία του σε χρήστες) καθώς και αυθαίρετων κανόνων για το αν και σε ποιούς θα στέλνονται αυτές οι αναφορές.

Για τα παραπάνω ο ανάδοχος θα πρέπει να επιδείξει κατά τη διάρκεια των δοκιμών ότι τόσο η μορφή των αναφορών όσο και τα δεδομένα που θα περιέχουν όσο και οι προσβάσεις μπορούν να διαμορφωθούν μέσω του γραφικού περιβάλλοντος του GUI καθώς και ότι μπορούν να γίνουν download και να σταλούν με e-mail οι αναφορές στα format που αναφέρθηκα δημιουργώντας αναφορές επίδειξης.


Έργο ΑΝΝΑ

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

• Συγκεντρωτική αναφορά με στοιχεία ταξιδιών για συγκεκριμένο λιμένα και προσβάσεις μόνο από χρήστες του λιμένα, με φίλτρα για τις ημερομηνίες, το όνομα του πλοίου κλπ

• Συγκεντρωτική αναφορά με στοιχεία όλων των τελευταίων ταξιδιών με πρόσβαση μόνο από συγκεκριμένους χρήστες

• Αναλυτική αναφορά με στοιχεία ενός ταξιδιού η οποία θα εμφανίζεται όταν ο χρήστης κάνει κλικ στο id του ταξιδιού από τα 1,2. Πρέπει να γίνεται έλεγχος αν υπάρχουν κατάλληλες προσβάσεις και εδώ.

• Αναλυτική αναφορά με στοιχεία ενός πλοίου η οποία θα εμφανίζεται όταν ο χρήστης κάνει κλικ στο όνομα του πλοίου από τις 1,2,3. Πρέπει να γίνεται έλεγχος αν υπάρχουν κατάλληλες προσβάσεις και εδώ.

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

8.4. Επιπλέον λειτουργικότητα για το SafeSeaNet

8.4.1. Μηχανισμός Αυτόματων Ελέγχων για εντοπισμό μη καταχωρημένων περιπτώσεων

Το σύστημα θα διαθέτει μηχανισμό που θα εκτελείται αυτόματα από το σύστημα ανά χρονικό διάστημα που θα έχει τη δυνατότητα να επιλέξει ο διαχειριστής της εφαρμογής και θα εκτελεί τουλάχιστον τα κάτωθι:

• Θα αξιοποιεί τα στοιχεία που συλλέγονται από το εθνικό δίκτυο AIS (στοιχεία πλοίου, γεωγραφική θέση, πορεία, ταχύτητα κ.α.) αναζητώντας περιπτώσεις για τις οποίες δεν έχουν καταχωρηθεί στο σύστημα αναφορές παρόλο που το πλοίο έχει καταπλεύσει ή αποπλεύσει σε/από λιμένα (δηλαδή μη συμμορφούμενα προς την εθνική νομοθεσία πλοία).

• Οι περιπτώσεις που θα εντοπίζονται με τον μηχανισμό αυτό, θα έχουν “φιλτραριστεί” από τον μηχανισμό παρακολούθησης προβλημάτων ώστε να αναδεικνύονται και οι περιπτώσεις που το σύστημα παρουσίαζε δυσλειτουργία. Συγκεκριμένα θα αναφέρεται η ιστορικότητα των δυσλειτουργιών (είδος προβλήματος, χρόνος έναρξης- λήξης κ.α.) που εντοπίστηκαν στο σύστημα το συγκεκριμένο χρονικό διάστημα προκειμένου να αξιολογούνται και να διερευνούνται περαιτέρω, από εξουσιοδοτημένους χρήστες.

• Για κάθε περίπτωση, αφού θα αφορά συγκεκριμένο λιμένα, θα ενημερώνει την αρμόδια Λιμενική Αρχή καθώς και τους χρήστες Κεντρικών Υπηρεσιών που θα έχουν αρμοδιότητα σε όλο τον Ελλαδικό χώρο.

8.4.2. Παρακολούθηση SafeSeaNet

Θα γίνεται αυτόματη παρακολούθηση της δραστηριότητας του συστήματος για την περιοχή δραστηριότητας κάθε Λιμενικής Αρχής. Ειδικότερα θα πρέπει να παρέχονται πληροφορίες μέσω αναφορών τουλάχιστον για τα ακόλουθα:


Έργο ΑΝΝΑ

α) Το σύνολο των αποσταλθέντων και ληφθέντων ανά τύπο μηνυμάτων για χρονική περίοδο που θα παραμετροποιείται από τους διαχειριστές.

β) Τα χρονικά διαστήματα για τα οποία δεν έγινε ανταλλαγή μηνυμάτων λόγω προβλήματος οφειλόμενου σε οποιαδήποτε αιτία.

8.5. Παρουσίαση πληροφοριών / στατιστικών

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

• το σύνολο των στοιχείων μιας ή περισσοτέρων αναφορών που ικανοποιούν συγκεκριμένα κριτήρια

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

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

Το παραπάνω σύνολο των μηνυμάτων θα μπορεί να αναζητηθεί ενδεικτικά με βάση τα παρακάτω κριτήρια:

• Τύπος μηνύματος

• Τύπος αναφοράς (π.χ. Port Plus Notification)

• I.M.O. Number ή/και M.M.S.I. ή/και Όνομα πλοίου.

• Κατάσταση αποστολής, Ένδειξη αποδεικτικού μηνύματος(receipt)

• Ημερομηνία/Ώρα Απόκρισης

• Δημιουργός Μηνύματος

Επίσης θα υπάρχει η δυνατότητα απευθείας πρόσβαση και στο περιεχόμενο των καταχωρήσεων από τις οποίες παρήχθησαν τα μηνύματα. Θα γίνεται αυτόματη παρακολούθηση της δραστηριότητας του συστήματος για την περιοχή δραστηριότητας συνολικά του συστήματος. Ειδικότερα θα πρέπει να παρέχονται πληροφορίες τουλάχιστον για τα ακόλουθα:

α) Το σύνολο των απεσταλμένων και ληφθέντων ανά τύπο μηνυμάτων για χρονική περίοδο που θα παραμετροποιείται από τους διαχειριστές.

β) Τα χρονικά διαστήματα για τα οποία δεν έγινε ανταλλαγή μηνυμάτων λόγω προβλήματος οφειλόμενου σε οποιαδήποτε αιτία.


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 9: Υποσύστημα Διαχείρισης και Εποπτείας (Management & Monitoring - Μ&M)

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

9.1. Γενικά

Το υποσύστημα πρόσβασης στα δεδομένα είναι μια Enterprise Web εφαρμογή αποτελούμενη από τρία ξεχωριστά επίπεδα: Web, Application και Database/Storage. Το επίπεδο Web ουσιαστικά προσφέρει ένα επίπεδο παρουσίασης για τους χρήστες ενώ στο Application Layer υπάρχουν τα domain objects της εφαρμογής και χρησιμοποιείται ως ενδιάμεση πρόσβαση προς το επίπεδο της αποθήκευσης.

Για το επίπεδο της βάσης δεδομένων θα χρησιμοποιείται η κεντρική βάση δεδομένων του Mid Office, οπότε θα πρέπει να υπάρχει πρόσβαση στον κόμβο του Mid Office (ή ακόμα και να γίνεται host στον κόμβο του Mid Office ανάλογα με τις επιλογές του αναδόχου). Επίσης, επειδή το M&M σύστημα θα αποθηκεύει μεγάλο όγκο από διάφορα στατιστικά στοιχεία θα πρέπει αυτά να εισάγονται σε ξεχωριστή και εξειδικευμένη βάση δεδομένων ώστε να μην επηρεάζεται η λειτουργία της κεντρικής βάσης.

Η εμφάνιση και η λειτουργικότητα του M&M (GUI) πρέπει να είναι παρόμοια και να ακολουθεί τις ίδιες αρχές με αυτές που αναλύονται στην ενότητα για το Front Office. Ο χρήστης δηλαδή βλέποντας το GUI του Front Office και το GUI του συστήματος πρόσβασης στα δεδομένα θα πρέπει να καταλαβαίνει ότι ανήκουν και τα δύο στην ενιαία ναυτιλιακή θυρίδα.

9.2. Ασφάλεια

Είναι απαραίτητο να διασφαλιστεί η ασφάλεια του εν λόγω συστήματος. Προς τούτο, θα πρέπει να επιτρέπονται μόνο συνδέσεις από το εσωτερικό δίκτυο του Α/ΛΣ-ΕΛΑΚΤ.

9.3. Ενσωμάτωση / ολοκλήρωση εποπτείας

Τα συστήματα monitoring όλων των επιμέρους συστατικών της ενιαίας ναυτιλιακής θυρίδας θα πρέπει να γίνονται integrate στο M&M. Αυτό σημαίνει ότι ο διαχειριστής θα μπορεί να βλέπει πχ τον αριθμό των ενεργών threads στον application server ή το πόσα μηνύματα προς επεξεργασία υπάρχουν στην ουρά μέσα από το περιβάλλον M&M και χωρίς να χρειάζεται να φύγει από το GUI του M&M.

Το σύστημα εποπτείας του πληροφοριακού συστήματος της ενιαίας ναυτιλιακής θυρίδας οφείλει να έχει μια κεντρική οθόνη εποπτείας η οποία θα δείχνει την κατάσταση


Έργο ΑΝΝΑ

υγείας (health status) όλων των επιμέρους υποσυστημάτων του συστήματος και συγκεκριμένα:

• Front Office

• Mid Office

• Ουρά μηνυμάτων Mid Office

• Βάση δεδομένων Mid Office

• Υποσύστημα πρόσβασης σε δεδομένα

• Συνδέσεις με backends

Ο κάθε διαχειριστής επιλέγοντας κάποιο από τα παραπάνω θα μπορεί να δει περισσότερες πληροφορίες για την κατάσταση κάθε υποσυστήματος πχ για το Front Office θα βλέπει την κατάσασταση των εικονικών μηχανών που το αποτελούν, του Application server, του Web Server κλπ.

Πέρα από την παραπάνω παρουσίαση, ο διαχειριστής θα μπορεί να δει από το M&M πληροφορίες για όλα τα συστατικά του συστήματος όπου και κατ’ ελάχιστον θα πρέπει να είναι

• Για όλες τις εικονικές μηχανές:

Real Time / average χρήση CPU, χρήση CPU / διεργασία, συνολική / ελεύθερη RAM, χρήση RAM / διεργασία, λίστα διεργασιών, αρ. thread / διεργασία, IP address, συνολικός / ελεύθερος χώρος ανά partition σκληρού δίσκου, χρήση δικτύου, ανοιχτές θύρες TCP (ρυθμίσεις firewall κάθε VM), uptime

• Για τους Load Balancers:

αρ. ενεργών συνδέσεων, αρ. ενεργών sticky session, realtime / average CPU , χρήση μνήμης

• Για τους Web servers:

αρ. ενεργών συνδέσεων, χρόνος εξυπηρέτησης τελευταίου request, μέσος όρος εξυπηρέτησης τελευταίων requests, χρήση μνήμης, αρ. ενεργών threads/processes

• Για τους Application servers:

Αρ. ενεργών threads/processes, αρ. ενεργών συνδέσεων με το web server, χρόνος εξυπηρέτησης τελευταίου request, μέσος όρος χρόνου εξυπηρέτησης τελευταίων requests, αρ. ανοιχτών συνδέσεων με τη βάση δεδομένων, μέγιστος αρ. συνδέσεων με τη βάση, κατάσταση σύνδεσης με την ουρά μηνυμάτων, κατάσταση σύνδεσης με τη βάση δεδομένων, αρ. ενεργών session, χρήση μνήμης

• Για την ουρά μηνυμάτων:

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


Έργο ΑΝΝΑ

δυνατότητα για alert όταν κάποιο μήνυμα παραμείνει περισσότερο από κάποιο χρονικό διάστημα στην ουρά προς αναμονή

• Για τις βάσεις δεδομένων:

ενεργές συνδέσεις προς τη βάση, μέγιστος αριθμός συνδέσεων προς τη βάση, σχήμα βάσης, χώρος που καταλαμβάνεται από κάθε πίνακα, χρόνος εκτέλεσης των 10 πιο αργών queries (και το ποια ήταν αυτά)

Για όλα τα παραπάνω πρέπει να υπάρχει ιστορικό με παραμετροποιήσιμο χρονικό διάστημα που θα κρατείται το ιστορικό και sampling time. Το στοιχεία αυτά δεν θα πρέπει να αποθηκεύονται στην κεντρική βάση δεδομένων του Mid office αλλά σε ξεχωριστή βάση δεδομένων εξειδικευμένη για αποθήκευση των στατιστικών στοιχείων. Θα πρέπει να εμφανίζονται στους διαχειριστές τόσο σε μορφή γραφημάτων όσο και να μπορούν να κατέβουν σε μορφή xls ή csv.

Σημειώνεται ότι η ΕΠΕ μπορεί να ζητήσει από τον ανάδοχο το Monitoring και επιπλέον στοιχείων ανάλογα με τις ανάγκες που θα παρουσιαστούν κατά την υλοποίηση του έργου.

9.4. Ειδοποιήσεις

Το M&M σύστημα πρέπει να δίνει τη δυνατότητα άμεσης ειδοποίησης των διαχειριστών εφαρμογής και συστήματος σε περίπτωση οποιουδήποτε προβλήματος κατά τη λειτουργία του συστήματος. Θα υπάρχει δυνατότητα εισαγωγής Alerts με Threshold για όλα τα υπό εποπτεία στοιχεία, της μορφής “όταν συμβεί το X στείλε e-mail στους Y”, όπου X μπορεί να ειναι “CPU Usage > 60% σε ένα server για πάνω από 1 λεπτό” ή “λιγότερη από 30% ελεύθερη μνήμη” από και το Y “διαχειριστές συστήματος”.

Πέρα από το thresholding, σε περίπτωση που υπάρχει οποιαδήποτε δυσλειτουργία στις εικονικές μηχανές, στους hosting servers αλλά και σε οποιοδήποτε επιμέρους τμήμα του συσήματος θα πρέπει άμεσα να ειδοποιούνται οι διαχειριστές συστήματος με e-mail και φυσικά να φαίνετα ξεκάθαρα στην κεντρική οθόνη εποπτείας που σημειώθηκε πιο πάνω.

9.5. Διαχείριση

Μέσω του υποσυστήματος διαχείρισης του M&M οι διαχειριστές θα μπορούν να παραμετροποιήσουν και να ενεργήσουν σε διάφορα σημεία της ενιαίας ναυτιλιακής θυρίδας, μερικά εκ των οποίων είναι τα εξής:

• Διαχείριση χρηστών και ομάδων

• Διαχείριση αιτημάτων χρηστών

• Διαχείριση M2M χρηστών

• Διαχείριση και δημιουργία Αναφορών

• Ενεργοποίηση / απενεργοποίηση backends

• Διαχείριση δικαιωμάτων διαχειριστών

• Διαχείριση βάσης πλοίων

• Ροές χειρισμού εσφαλμένων / μη παραδομένων μηνυμάτων

Όλες οι ενέργειες που γίνονται από τους διαχειριστές θα πρέπει να καταγράφονται αναλυτικά (ποιος, τι, πότε – auditing trail).


Έργο ΑΝΝΑ

Κάθε διαχειριστής θα μπορεί να έχει συγκεκριμένα δικαιώματα στο διαχειριστικό δηλαδή κάποιος διαχειριστής θα μπορεί να κάνει μόνο τη διαχείριση των απλών χρηστών ενώ κάποιος άλλος μόνο τη διαχείριση των αναφορών. Αυτά θα δίνονται από κάποιο superuser ο οποίος θα έχει όλα τα δικαιώματα.


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 10: Εξοπλισμός

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

10.1. Application Delivery Controller (ADC) – Load Balancer (Καλύπτει το πιλοτικό 1)

Ποσότητα 2

Να μπορεί να τοποθετηθεί στο προσφερόμενο ικρίωμα. ΝΑΙ

Η ικανότητα διαβίβασης δεδομένων (throughput) να είναι τουλάχιστον 500Mbps.

ΝΑΙ

Να υπάρχει η δυνατότητα αναβάθμισης του Throughput μέχρι τα 4Gbps χωρίς να γίνει αλλαγή στο Hardware του συστήματος (License key upgrade)

ΠΡΟΑΙΡΕΤΙΚΟ

Να διαθέτει εγκατεστημένη μνήμη RAM ≥ 8GB ΝΑΙ

Να υποστηρίζει ICMP-based on health monitoring ΝΑΙ

Να υποστηρίζει Traffic Redirection ΝΑΙ

Το Σύστημα να υποστηρίζει VRRP για υψηλή διαθεσιμότητα (HA) σε (ΑΑ) Active-Active και (ΑΒ) Active-Backup συνδεσμολογία

ΝΑΙ

Το Σύστημα να υποστηρίζει αυτόματη διαπραγμάτευση (auto-negotiation) σε χαλκό (copper) 10/100/1000 Ethernet Interfaces

ΝΑΙ

Το Σύστημα να υποστηρίζει ρυθμίσεις σε πολλαπλά VLAN’s ΝΑΙ

Το Σύστημα να υποστηρίζει δρομολόγηση πρωτοκόλλων: OSPF, RIP 1 και RIP 2

ΝΑΙ

Να υποστηρίξει Επιτάχυνση εφαρμογών (Application Acceleration) ΝΑΙ

Να διαθέτει SSL Επιτάχυνση (SSL Acceleration) ΝΑΙ

Να μπορεί να υποστηρίξει κεντρική διαχείριση Certificates (Central Certificate Management)

ΝΑΙ

Να υποστηρίζει TCP Multiplexing ΝΑΙ

Να υποστηρίζει Web και Selective συμπίεση ΝΑΙ

Να υποστηρίζει virtualized environments ΝΑΙ

Nα υποστηρίζει εικονικό application delivery controller (V-ADC) σε ΠΡΟΑΙΡΕΤΙΚΟ


Έργο ΑΝΝΑ

λογισμικό virtualisation

10.2. Blade Technology Server (Καλύπτει τα πιλοτικά 1-4 καθώς και το disaster recovery)

10.2.1. Blade Chassis

Ποσότητα (τεμάχια):

2

(1 + 1 disaster recovery)

Θα τοποθετηθεί σε κατάλληλο ικρίωμα με σύστημα ελέγχου KVM Switch (Πληκτρολόγιο, οθόνη, συσκευή κατάδειξης)

ΝΑΙ

Να διαθέτει hot swap και redundant power supplies και hot swap και redundant fans (όσα είναι αναγκαία για την υποστήριξη του μέγιστου αριθμού Blades που μπορεί να δεχτεί το Blade Chassis)

ΝΑΙ

Το Blade Chassis να ακολουθεί σχεδιασμό υψηλής διαθεσιμότητας σε όλα τα στοιχεία του χωρίς μονό πιθανό στοιχείο αστοχίας (single point of failure). Συγκεκριμένα να εξασφαλίζεται η υψηλή διαθεσιμότητα στα παρακάτω σημεία:

τροφοδοσία ρεύματος του Blade Chassis

τροφοδοσία ρεύματος των Blade Servers

η επικοινωνία LAN/SAN του Blade Chassis

η επικοινωνία LAN/SAN των Blade Servers

η ψύξη όλων των μερών του Blade Chassis

ΝΑΙ

Για κάθε προσφερόμενο Blade Chassis να υπάρχει η δυνατότητα για υποδοχή τουλάχιστον δεκατεσσάρων (14) Blade Servers των οποίων η προσθαφαίρεση να γίνεται hot swap.

ΝΑΙ

Το Blade Chassis να μπορεί να υποδεχτεί ταυτόχρονα Blade Servers με λειτουργικό Windows και Linux.

ΝΑΙ

Το Blade Chassis να διαθέτει σε υψηλή διαθεσιμότητα μονάδες απομακρυσμένης διαχείρισης του ιδίου και όλων των εγκατεστημένων Blade Servers. Η διαχείριση να μπορεί να γίνει με ασφάλεια μέσω δικτύου ethernet χωρίς την ανάγκη εγκατάστασης ειδικού λογισμικού στο σταθμό εργασίας (web-browser interface)

ΝΑΙ

Να παρέχεται η δυνατότητα διαχείρισης εικονικών διευθύνσεων και θυρών επικοινωνίας από τον Βlade Server προς το δίκτυο ethernet και το SAN (Storage Area Network).

ΝΑΙ

Το λογισμικό διαχείρισης να δίνει την δυνατότητα παρακολούθησης της λειτουργίας όλου του εξοπλισμού σε επίπεδο hardware και εντοπισμού ήδη εκδηλωθεισών βλαβών.

ΝΑΙ

Να παρέχεται λειτουργία απομακρυσμένης διαχείρισης των servers μέσω γραφικού περιβάλλοντος, το οποίο θα εξασφαλίζει μεταξύ άλλων διαδικασία ενημέρωσης κάθε Blade Server με το τελευταίο BIOS, εγκατάστασης έτοιμης σύνθεσης λειτουργικού

ΝΑΙ


Έργο ΑΝΝΑ

συστήματος και εφαρμογών σε κάθε έναν από τους Blade Servers, διακοπής λειτουργίας (power off) ενός Blade Server και αλλαγής του Boot Sequence.

Να παρέχεται λειτουργία KVM (Kbd-Video-Mouse) για τους Blade Servers μέσω δικτύου ethernet (είτε μέσω των μονάδων απομακρυσμένης διαχείρισης είτε με ξεχωριστά KVM switches).

ΝΑΙ

Να παρέχεται λειτουργία διαχείρισης της ηλεκτρικής ενέργειας (Power management) για τους Blade Servers & το Blade Chassis

ΝΑΙ

Να παρέχεται ικανός αριθμός 1Gb ethernet ports (φυσικών ή virtual) πλήρως ενεργοποιημένων που να υποστηρίζουν το μέγιστο αριθμό Blade Servers που μπορεί να δεχτεί το Blade Chassis.

ΝΑΙ

Να παρέχεται ικανός αριθμός storage switches πλήρως ενεργοποιημένων (8Gb Fiber Channel) στο Blade Chassis ή εξωτερικά, ώστε να καλύπτει τον απαιτούμενο αριθμό θυρών των Blade Servers.

Τα προτεινόμενα storage switches να υποστηρίζουν το μέγιστο αριθμό Blade Servers που μπορεί να δεχτεί το Blade Chassis.

ΝΑΙ

Το Blade Chassis να διαθέτει οπτικές ενδείξεις διαγνωστικών για τον εντοπισμό βλαβών ακόμη κι όταν δεν τροφοδοτείται με ρεύμα.

ΝΑΙ

Το Blade Chassis να διαθέτει δυνατότητα πρόβλεψης βλαβών πριν συμβούν που να καλύπτει:

Α. μνήμη,

Β. δίσκους,

Γ. τροφοδοτικά

Δ. επεξεργαστές

Ε. ψύκτες (fans)

Α. ΝΑΙ

Β. ΝΑΙ

Γ. ΝΑΙ

Δ. ΝΑΙ

Ε. ΝΑΙ

Να εξασφαλιστεί η πλήρης συμβατότητα των προτεινόμενων ethernet switches με την υφιστάμενη υποδομή ethernet του Computer Room του φορέα που αποτελείται από εξοπλισμό Nortel (ERS 8600, 5530-24TFD).

ΝΑΙ

10.2.2. Blade Servers

Ποσότητα 8 (2 ανά πιλοτικό) + 4 [(1 ανά πιλοτικό) disaster recovery]

O κάθε Blade Server να διαθέτει 2 επεξεργαστές με αριθμό πυρήνων (ανά επεξεργαστή) ≥8 και συχνότητα λειτουργίας ≥2GHz. Διευκρινίζεται ότι η ανωτέρω συχνότητα λειτουργίας αναφέρεται σε τεχνολογία FSB. Σε περίπτωση που προσφερθεί εξοπλισμός που χρησιμοποιεί άλλου είδους τεχνολογία, ο υποψήφιος θα πρέπει να παρέχει ανάλογη τεκμηρίωση που θα αποδεικνύει την αντιστοιχία με τη συγκεκριμένη απαίτηση.

ΝΑΙ

O κάθε Blade Server να διαθέτει εγκατεστημένη μνήμη RAM ≥ 512GB ΝΑΙ


Έργο ΑΝΝΑ

O κάθε Blade Server να διαθέτει redundant συνδέσεις επικοινωνίας με το Blade chassis ΠΡΟΑΙΡΕΤΙΚΟ

O κάθε Blade Server να διαθέτει δύο εσωτερικούς δίσκους χωρητικότητας τουλάχιστον 128 GB έκαστος τύπου SSD σε διάταξη hardware- mirror (Raid1)

ΝΑΙ

O κάθε Blade Server να διαθέτει τουλάχιστον τέσσερεις φυσικές θύρες σύνδεσης 1GB ethernet (LAN).

ΝΑΙ

O κάθε Blade Server να διαθέτει δυο θύρες οπτικής σύνδεσης πλήρως ενεργοποιημένες (FC SAN) 8GB με το σύστημα κεντρικής αποθήκευσης (SAN)

ΝΑΙ

Οι προτεινόμενοι servers να είναι πιστοποιημένοι για λειτουργικό MS Windows 2008 Server & LINUX. Να παραδοθεί σχετικό πιστοποιητικό από τον κατασκευαστή μαζί με τον εξοπλισμό.

ΝΑΙ

Οι προτεινόμενοι servers να είναι πιστοποιημένοι για το λογισμικό εικονικών μηχανών που θα προσφερθεί

ΝΑΙ

O κάθε Blade Server να διαθέτει οπτικές ενδείξεις διαγνωστικών για τον εύκολο εντοπισμό βλαβών οι οποίες να λειτουργούν και αν ο Blade Server δεν τροφοδοτείται με ρεύμα.


Κάθε σύστημα Blade να συνοδεύεται από άδεια χρήσης λειτουργικού συστήματος Windows Server τύπου datacenter της τελευταίας έκδοσης

NAI

10.2.3. Λογισμικό Virtualization

Να εγκαθίσταται απευθείας στους προσφερόμενους servers χωρίς να απαιτεί εγκατάσταση κάποιου λειτουργικού (Bare Metal Architecture).

ΝΑΙ

Υποστήριξη CPU Virtualisation NAI

Υποστήριξη Storage Virtualisation NAI

Υποστήριξη Network Virtualisation ΝΑΙ

Να συνεργάζεται πλήρως με τον προσφερόμενο εξοπλισμό (Blade Servers & SAN Storage).

NAI

Nα υποστηρίζει τουλάχιστον Windows server- Linux NAI

Να εξασφαλίζει υψηλή διαθεσιμότητα στους Virtual Servers και στο Virtualization Software με αυτόματη μετάπτωση-μεταφορά των εικονικών μηχανών μεταξύ των φυσικών μηχανών σε περίπτωση βλάβης.

NAI

Να εξασφαλίζει τη δυνατότητα λήψης αντίγραφων ασφαλείας των εικονικών μηχανών χωρίς να επηρεάζονται οι εφαρμογές και οι χρήστες.

NAI

Να προσφερθεί ικανός αριθμός αδειών χρήσης για τη κάλυψη του συνόλου των προσφερόμενων Blade Servers και για τουλάχιστον πενήντα (50) εικονικές μηχανές.

NAI

Να παρέχονται και να εγκαθίστανται νεότερες εκδόσεις/υποεκδόσεις του προσφερόμενου λογισμικού Virtualization για χρονική διάρκεια >=1 ετών.

NAI

Να μπορεί να οριστεί προγραμματισμένη αυτόματη μετάπτωση εικονικών μηχανών από μια φυσική μηχανή σε μια άλλη σύμφωνα με κανόνες που θα ορίζει ο χρήστης.

ΝΑΙ


Έργο ΑΝΝΑ

Να υποστηρίζεται η δυνατότητα εκχώρησης περισσότερης μνήμης στις εικονικές μηχανές από όση είναι φυσικά διαθέσιμη.

ΝΑΙ

Παροχή γραφικής διεπαφής χρήστη (graphical user interface) η οποία να επιτρέπει την κεντρική διαμόρφωση και διαχείριση του εικονικού περιβάλλοντος.

NAI

Δυνατότητα προσθήκης/αφαίρεσης επεξεργαστών (CPU) και μνήμης (RAM) σε εικονικές μηχανές χωρίς διακοπή λειτουργίας τους.

NAI

Δυνατότητα διάθεσης εικονικού αποθηκευτικού χώρου ξεχωριστά σε κάθε εικονική μηχανή

ΝΑΙ

Δυνατότητα μετακίνησης εικονικής μηχανής σε αποθηκευτικό χώρο διαφορετικής αρχιτεκτονικής

NAI

Δυνατότητα δημιουργίας και διαχείρισης εικονικού δικτύου NAI

Δυνατότητα υποστήριξης αρχιτεκτονικής αποθηκευτικού χώρου Fiber Channel, iSCSI και NAS

NAI

Δυνατότητα υποστήριξης αρχιτεκτονικής σκληρών δίσκων τύπου FC/SAS/SATA/SSD NAI

Δυνατότητα δημιουργίας νέων μηχανών από αντιγραφή υφιστάμενων μηχανών ΝΑΙ

Αυτόματη μετακόμιση εικονικών μηχανών σε φυσικό εξυπηρετητή με διαθέσιμους πόρους για εξοικονόμηση ενέργειας

NAI

Δυνατότητα αναβάθμισης λογισμικού virtualization των φυσικών εξυπηρετητών χωρίς διακοπή λειτουργίας της εικονικής υποδομής.

NAI

Δυνατότητα παρακολούθησης του φόρτου εργασίας των εικονικών μηχανών και των φυσικών μηχανών

NAI

Δυνατότητα προειδοποίησης σε περίπτωση υπερφόρτωσης εργασίας εικονικών μηχανών και φυσικών μηχανών

ΝΑΙ

Δυνατότητα γρήγορης δημιουργίας εφεδρικών αρχείων εικονικών μηχανών χωρίς την ανάγκη χρήσης επιπλέον λογισμικού

NAI

Δυνατότητα γρήγορης επαναφοράς εικονικής μηχανής από εφεδρικό αρχείο χωρίς την ανάγκη χρήσης επιπλέον λογισμικού

NAI

Δυνατότητα (πλήρως ενεργοποιημένη) επικοινωνίας και συγχρονισμού μεταξύ των δύο συστημάτων (κεντρικό και recovery blade system) που θα προσφερθούν

ΝΑΙ

10.3. Σύστημα κεντρικής αποθήκευσης δεδομένων (SAN) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)

Αριθμός Μονάδων 2 (1 + 1 disaster recovery)


Έργο ΑΝΝΑ

Να μπορεί να τοποθετηθεί σε συμβατικά standard server rack (19 inch) μαζί με τον εξοπλισμό Blade Chassis

ΝΑΙ

Να ακολουθεί αρθρωτή αρχιτεκτονική με μονάδες ελέγχου δίσκων (controllers) και μονάδες υποδοχής δίσκων

ΝΑΙ

Να διαθέτει διπλές μονάδες ελέγχου δίσκων (dual active-active controllers) με συνολικά τουλάχιστον 8GB cache

ΝΑΙ

Υποστήριξη μεταφοράς δεδομένων από/προς τους ελεγκτές διασύνδεσης (Transfer rate) ≥ 4Gbps

ΝΑΙ

Να διαθέτει αρχιτεκτονική υψηλής διαθεσιμότητας σε όλα τα σημεία του ΝΑΙ

Να διαθέτει διαγνωστικά εργαλεία για την υγεία των μερών του συστήματος.

ΝΑΙ

Να διαθέτει διπλά κανάλια σύνδεσης των δίσκων στους controllers (για μεγαλύτερες επιδόσεις και αξιοπιστία).

ΝΑΙ

Να μπορεί να υποστηρίξει συνολικά αριθμό δίσκων ≥200 με μονάδες επέκτασης δίσκων

ΝΑΙ

Να μπορεί να υποστηρίξει τοπολογίες Raid 0,1,5,10 ΝΑΙ

Να τοποθετηθούν δίσκοι SSD (Solid State Drives) ΝΑΙ

Να υποστηρίζει τη συνύπαρξη δίσκων διαφορετικών τεχνολογιών και χωρητικοτήτων στις μονάδες επέκτασης δίσκων.


Να διαθέτει συνολικά ≥4 οπτικές θύρες (8Gbps FC ports) και ≥4 θύρες iSCSI πλήρως ενεργοποιημένες

ΝΑΙ

Να περιλαμβάνει λογισμικό Multipath για απεριόριστο αριθμό server και δυνατότητα υποστήριξης λειτουργικών συστημάτων Windows & Linux και του λογισμικού εικονικών μηχανών που θα προσφερθεί

ΝΑΙ

Να υποστηρίζει την τεχνολογία Wide Striping για τους δίσκους. ΠΡΟΑΙΡΕΤΙΚΟ

Να διαθέτει λειτουργία παροχής εικονικής χωρητικότητας σε λογικούς δίσκους μεγαλύτερης της φυσικά διαθέσιμης χωρητικότητας (Thin Provisioning)

ΝΑΙ

Να διαθέτει δυνατότητα δημιουργίας λογικών δίσκων σε διάταξη πιστών αντιγράφων μεταξύ τους (Mirroring)

ΝΑΙ

Να διαθέτει δυνατότητα λειτουργίας απομακρυσμένης διπλοποίησης δεδομένων (remote mirroring) με αποστολή των αποθηκευμένων δεδομένων σε άλλο αποθηκευτικό σύστημα σε άλλο κτίριο ή γεωγραφική τοποθεσία με σύγχρονο και ασύγχρονο τρόπο (Global & Metro Mirror).


Να διαθέτει γραφικό εργαλείο διαχείρισης του συστήματος χωρίς ανάγκη εγκατάστασης προγράμματος (π.χ. μέσω web-browser).

ΝΑΙ


Έργο ΑΝΝΑ

Να παρέχεται η δυνατότητα ολοκλήρωσης - ενοποίησης του εργαλείου διαχείρισης του SAN με το αντίστοιχο εργαλείο διαχείρισης των Blade servers.

ΝΑΙ

Το εργαλείο διαχείρισης του SAN να παρέχει δυνατότητα ανάλυσης των επιδόσεων του συστήματος σε επίπεδο εφαρμογής και καταγραφή ιστορικού επιδόσεων

ΝΑΙ

Συνολική ωφέλιμη χωρητικότητα των προσφερομένων δίσκων τύπου SSD με τοπολογία Raid 5 ή ανώτερη.

≥40 ΤΒ για το κεντρικό σύστημα

≥20 ΤΒ για το disaster recovery

Να προσφερθούν 10 εφεδρικοί SSD δίσκοι ΝΑΙ

Να υποστηρίζεται λειτουργικότητα δίσκου Hot-spare και να διατεθούν τουλάχιστον δύο (02) ανά τύπο δίσκου

ΝΑΙ

Να προσφερθούν όλα τα μέρη-υλικά (fiber channels, SFP κτλ) για την σύνδεση όλου του αναφερόμενου εξοπλισμού για το σχηματισμό του SAN με τη λογική “no-single-point-of-failure”

ΝΑΙ

Εξασφάλιση εργαλείου - λογισμικού αυτόματης μετάπτωσης (Physical to Virtual) μηχανών με άδεια χρήσης για τουλάχιστον πενήντα (50) μεταπτώσεις.

ΝΑΙ

Να υποστηρίζει παλαιότερες εκδόσεις λειτουργικών συστημάτων που είναι εγκατεστημένα και λειτουργούν στο φορέα (Windows ΝΤ, 2000, 2003)

ΝΑΙ

Δυνατότητα (πλήρως ενεργοποιημένη) επικοινωνίας και συγχρονισμού μεταξύ των δύο συστημάτων (κεντρικό και recovery blade system) που θα προσφερθούν

ΝΑΙ

10.4. Οπτικοί Μεταγωγείς Δεδομένων για το SAN (Optical SAN Switch) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)

ΓΕΝΙΚΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ

Αριθμός μονάδων. 2 + 2 για το disaster recovery

Να αναφερθεί ο κατασκευαστής και το μοντέλο. NAI

Εγκατάσταση σε διάταξη υψηλής διαθεσιμότητας (failover). NAI

Να αναφερθεί και να τεκμηριωθεί ο τρόπος διάταξης (πχ Active-Active, Active-Passive ή άλλος)

ΝΑΙ

Εγκατάσταση εντός του προσφερομένου ικριώματος. Να συνοδεύεται από όλα τα απαιτούμενα για την εγκατάσταση υλικά (συνδετήρες, καλώδια κλπ).

NAI

Τροφοδοσία AC, 220V. ΝΑΙ

Εγκατεστημένη εφεδρική τροφοδοσία ΝΑΙ


Έργο ΑΝΝΑ

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

ΝΑΙ

ΤΕΧΝΙΚΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ

Να καταγραφούν εάν υπάρχουν κάρτες επέκτασης, αρθρώματα, οπτικοί μετατροπείς, κτλ.

ΝΑΙ

Να υποστηρίζεται η τεχνολογία hot swap για το σύστημα τροφοδοσίας. ΝΑΙ

Όλες οι διαθέσιμες θέσεις για τροφοδοτικά να είναι δεσμευμένες με τροφοδοτικά.

ΝΑΙ

Αριθμός πλήρως ενεργοποιημένων οπτικών SFP θυρών. ≥ 48

Ταχύτητα κάθε οπτικής SFP θύρας. Έως 16 Gbps

Δυνατότητα υποστήριξης ταχυτήτων 2,4,8,10,16 Gbps NAI

Αθροιστικό bandwidth συσκευής. ≥ 384 Gbps

Υποστήριξη τεχνολογίας VSAN ή αντίστοιχης. (πχ zoning) ΝΑΙ

Αριθμός υποστηριζόμενων VSANs ΝΑ ΑΝΑΦΕΡΘΕΙ

Υποστήριξη τεχνικών εξασφάλισης ποιότητας υπηρεσιών (QoS). ΝΑΙ

Υποστήριξη RADIUS και TACACS ΝΑΙ

Υποστήριξη εργαλείων διάγνωσης κατάστασης (diagnostics) και αντιμετώπισης προβλημάτων (troubleshooting)

ΝΑΙ

Να αναφερθούν τα ανωτέρω εργαλεία διάγνωσης κατάστασης (diagnostics) και αντιμετώπισης προβλημάτων (troubleshooting)

ΝΑ ΑΝΑΦΕΡΘΟΥΝ

Να διατεθούν οπτικοί πομποδέκτες (optical transceivers) για το σύνολο των θυρών του προσφερόμενου εξοπλισμού.

ΝΑΙ

Να διατεθούν 4 εφεδρικοί οπτικοί πομποδέκτες (optical transceivers) ΝΑΙ

ΔΙΑΧΕΙΡΙΣΗ

Ενδεικτικές λυχνίες για την κατάσταση των συνδέσεων των θυρών. ΝΑΙ

Λογισμικό διαχείρισης συσκευής. Να δοθεί περιγραφή των λειτουργικών & τεχνικών χαρακτηριστικών (συμπεριλαμβάνονται οι άδειες χρήσης).

ΝΑΙ

Υποστήριξη απομακρυσμένης διαχείρισης. ΝΑΙ

Υποστήριξη SNMP. ΝΑΙ

Υποστήριξη Secure FTP, SSH. ΝΑΙ

10.5. Αυτοματοποιημένο Σύστημα Λήψης Αντιγράφων Ασφάλειας (Tape Library System) (Καλύπτει το πιλοτικό 2)


Έργο ΑΝΝΑ


Αριθμός μονάδων 1


Εγκατάσταση εντός προσφερομένου ικριώματος. Να συνοδεύεται από όλα τα απαιτούμενα για την εγκατάσταση υλικά (συνδετήρες, καλώδια κλπ).

NAI

Τροφοδοσία AC, 220V. ΝΑΙ

Εγκατεστημένη εφεδρική τροφοδοσία ΝΑΙ

Διάθεση όλου του παθητικού εξοπλισμού που απαιτηθεί για την εγκατάσταση της συσκευής (καλώδια, μετατροπείς κλπ).

ΝΑΙ


Τύπος FC-Drive Τουλάχιστον LTO-6

Αριθμός FC-DriveΙκανός για να καλύψει χωρητικότητα 300 TB (με συμπίεση) και τουλάχιστον 4

Αριθμός υποδοχών (slots)Ικανός για να καλύψει χωρητικότητα 300 TB (με συμπίεση) και τουλάχιστον 48

Αριθμός Παρεχόμενων ΚασετώνΊσος με το πλήθος των υποδοχών (slots)

Τύπος κασετών Τουλάχιστον LTO-6

Διάθεση επιπλέον εφεδρικών κασετών ίδιου τύπου με το προηγούμενο στοιχείο

10% επί του επί του ανωτέρω αριθμού παρεχόμενων κασετών

Ρομποτικό σύστημα αδιάλειπτης λειτουργίας ΝΑΙ

Κρυπτογράφηση δεδομένων ΝΑΙ

Συμπίεση δεδομένων ΝΑΙ

Διασύνδεση μέσω του προσφερόμενου οπτικού san switch NAI

Ταχύτητα και τύπος διασύνδεσης 8 Gb FC

Εφεδρική διασύνδεση με το οπτικό san switch 8 Gb FC NAI

Σύστημα tape bar code label ΠΡΟΑΙΡΕΤΙΚΟ

Δυνατότητα επέκτασης σε drives ή/και σε υποδοχές (slots) είτε στην ίδια συσκευή είτε με την προσθήκη εξωτερικών μονάδων


Δυνατότητα διαμερισματοποίησης (partitioning) σε κάθε drive ΠΡΟΑΙΡΕΤΙΚΟ


Διεπαφές (π.χ. RJ-45 Fast Ethernet) για τις λειτουργίες διαχείρισης Να αναφερθούν


Έργο ΑΝΝΑ

Ενδεικτικές λυχνίες για την κατάσταση λειτουργίας του συστήματος. ΝΑΙ

Λογισμικό διαχείρισης συσκευής. (συμπεριλαμβάνονται οι άδειες χρήσης).

ΝΑΙ

Διαγνωστικοί Έλεγχοι ΝΑΙ

Απομακρυσμένη διαχείριση ΠΡΟΑΙΡΕΤΙΚΟ

ΛΟΓΙΣΜΙΚΟ ΛΗΨΗΣ ΑΝΤΙΓΡΑΦΩΝ ΑΣΦΑΛΕΙΑΣ

Αν απαιτείται εγκατάσταση σε αφοσιωμένο εξυπηρετητή, να προσφερθεί stand alone εξυπηρετητής από τον ανάδοχο.

ΝΑΙ

Υποστήριξη full, incremental και differential backup ΝΑΙ

Δυνατότητα deduplication ΠΡΟΑΙΡΕΤΙΚΟ

Προσφορά όλων των απαραίτητων αδειών χρήσης, ώστε να είναι δυνατή η λήψη αντιγράφων ασφαλείας από:

- SAN συνολικής χωρητικότητας 100 ΤΒ ΝΑΙ

- Εικονικές μηχανές που θα προσφερθούν στο πλαίσιο του παρόντος έργου

ΝΑΙ

Άδειες χρήσης για λήψη αντιγράφων ασφαλείας χωρίς τη διακοπή υπηρεσιών λειτουργίας των εξυπηρετητών για το υπό προμήθεια σύστημα (on-line backup).

ΝΑΙ

Επιπλέον άδειες χρήσης του προηγούμενου στοιχείου για εξυπηρετητές φυσικούς ή εικονικούς με λειτουργικά συστήματα Windows ή Linux

≥ 10

10.6. Ικρίωμα (Rack) (Καλύπτει τα πιλοτικά 1-4 καθώς και το disaster recovery)


Επαρκής αριθμός μονάδων για το σύνολο του προσφερόμενου εξοπλισμού.

ΝΑΙ


ΤΕΧΝΙΚΑ ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΙΚΡΙΩΜΑΤΟΣ

Καμπίνα μεταλλική, δαπέδου με ροδάκια και φρένα και πρόβλεψη για αυξημένη ανθεκτικότητα, προστασία από διάβρωση και αντοχή στα στατικά φορτία.

ΝΑΙ

Μέγεθος: Όχι πιο ψηλό/ά από διακόσια δέκα εκατοστά (210 cm). Να αναφερθούν οι διαστάσεις.

ΝΑΙ

Εμπρόσθια αφαιρούμενη πόρτα με οπές εξαερισμού (διάτρηση). ΝΑΙ

Οπίσθια αφαιρούμενη πόρτα με οπές εξαερισμού (διάτρηση). ΝΑΙ


Έργο ΑΝΝΑ

Επιπλέον σύστημα ψύξης με ανεμιστήρες. ΠΡΟΑΙΡΕΤΙΚΟ

Πολύπριζο με προστασία RF και υποδοχές επαρκείς και κατάλληλες για τη διασύνδεση του εξοπλισμού (που θα εγκατασταθεί στο εσωτερικό της μονάδας). Ύπαρξη δύο επιπλέον ελεύθερων υποδοχών.

ΝΑΙ

Βραχίονες διαχείρισης καλωδίων (Cable Management Arms). ≥2

Ράφια στήριξης εξοπλισμού που δεν είναι rack mounted ≥1

Κόμβος γείωσης σύμφωνα με το ΕΝ 50174. ΝΑΙ

Τα πλαϊνά μέρη θα είναι αφαιρούμενα. NAI

Δυνατότητα προσπέλασης συσκευών από εμπρόσθια & οπίσθια πλευρά. ΝΑΙ

Να προσφερθούν από τον Ανάδοχο όλα τα απαιτούμενα καλώδια για τη διασύνδεση όλων των συσκευών.

ΝΑΙ

ΣΥΣΤΗΜΑ ΕΛΕΓΧΟΥ KVM SWITCH

Να αναφερθεί ο κατασκευαστής και το μοντέλο της οθόνης. ΝΑΙ

Τύπος οθόνης: TFT έγχρωμη. Να αναφερθεί η τεχνολογία (πχ LCD, LED). ΝΑΙ

Μέγεθος διαγωνίου οθόνης ≥ 17 ίντσες. NAI

Να αναφερθεί η μέγιστη υποστηριζόμενη ανάλυση της οθόνης. ΝΑΙ

Πληκτρολόγιο τύπου QWERTY, με μόνιμη αποτύπωση των ελληνικών και λατινικών χαρακτήρων σε κάθε πλήκτρο.

ΝΑΙ

Συσκευή κατάδειξης (touchpad) ενσωματωμένη στο σύστημα. ΝΑΙ

Να μπορεί να τοποθετηθεί στο ικρίωμα (rack mounted). ΝΑΙ

Ικανό αριθμό θυρών ώστε να καλύπτει τον εξοπλισμού που θα εγκατασταθεί στο/στα ικρίωμα/ικριώματα

ΝΑΙ

Καλώδια διασύνδεσης ώστε να καλύπτουν τον εξοπλισμό που θα εγκατασταθεί στο/στα ικρίωμα/ικριώματα.

ΝΑΙ

10.7. Μεταγωγείς δεδομένων για διαχείριση (Management Switches) (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)


Αριθμός μονάδων. 2+ 2 disaster recovery


Εγκατάσταση εντός του προσφερομένου ικριώματος. Να συνοδεύεται από όλα τα απαιτούμενα για την εγκατάσταση υλικά (συνδετήρες, καλώδια κλπ)

NAI


Έργο ΑΝΝΑ


Θύρες Ethernet 10/100/1000 Mbps ≥ 48

Υποστήριξη τεχνικών εξασφάλισης ποιότητας υπηρεσιών (QoS). ΝΑΙ

Ελάχιστη μνήμη flash (MB) 32

Μνήμη DRAM (MB) 64

Αριθμός υποστηριζόμενων VLAN Να αναφερθεί

Υποστήριξη IPv4/IPv6 NAI


Ενδεικτικές λυχνίες για την κατάσταση των συνδέσεων των θυρών. ΝΑΙ

Λογισμικό Διαχείρισης συσκευής. Να δοθεί περιγραφή των λειτουργικών & τεχνικών χαρακτηριστικών.

ΝΑΙ

Υποστήριξη απομακρυσμένης διαχείρισης (πρωτόκολλα SSH και SNMP). ΝΑΙ

Υποστήριξη Telnet/SSH ΝΑΙ

Υποστήριξη διαμόρφωσης παραμέτρων (configuration) μέσω Web browser.

ΝΑΙ

10.8. Εξυπηρετητές Διαχείρισης Συστημάτων Αποθήκευσης (Καλύπτει το πιλοτικό 2 καθώς και το disaster recovery)

Αριθμός μονάδων 2

Επεξεργαστές >=2

Αριθμός πυρήνων >=6

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

>=2.6 GHz

Κύρια μνήμη (RAM)

Μέγεθος >=128GB

Μέγεθος μέγιστης υποστηριζόμενης μνήμης >=256GB

Τύπος DDR3 ή νεότερη διαθέσιμη κατά την ημερομηνία διεξαγωγής του διαγωνισμού

Η συνολική προσφερόμενη μνήμη να αποτελείται από τουλάχιστον δύο (2) τεμάχια [πχ 2GB -> 2x1GB]

ΝΑΙ


Έργο ΑΝΝΑ

Σκληροί Δίσκοι (HDD) ΝΑΙ

Τύπος – χωρητικότητα – εσωτερικών δίσκων SSD >=500GB

Αριθμός εσωτερικών δίσκων >=4

RAID 0, 1, 5, 10

Δίσκοι συστήματος σε διάταξη mirror ΝΑΙ

Επιπλέον εφεδρικοί δίσκοι >=2

Τροφοδοτικό επαρκούς ισχύος Hot Swap ΝΑΙ

Επιπλέον Τροφοδοτικό Hot Swap ΝΑΙ

Δίαυλοι επικοινωνίας ΝΑΙ

Ενσωματωμένος Gigabit Ethernet Adapter (10/100/1000 Mbps), RJ 45 >=2

PCI - Express x 4 >=2

Θύρες USB 2.0 >=2

Σειριακή Θύρα >=1

Πλήθος Fiber Channel PCI Express Cards 2

Fiber Channel PCI Express Card Speed >=8Gbps

Οπτικά μέσα DVD±RW Double layer

Δυνατότητα Τοποθέτησης σε Rack ΝΑΙ

Εγκατεστημένο Λειτουργικό Σύστημα

Κατάλληλο λειτουργικό σύστημα με τα ακόλουθα χαρακτηριστικά:

- Να είναι σε παραθυρικό περιβάλλον.

- Να είναι πλήρως συμβατό με τον προσφερόμενο εξοπλισμό.

- Να συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

-Να είναι 64bit

Άλλο Λογισμικό - Λογισμικό προστασίας από ιούς και κακόβουλο λογισμικό με δυνατότητα αυτόματης ανανέωσης μέσω διαδικτύου συνοδευόμενο από άδεια χρήσης για τουλάχιστον 2 έτη.

Πλήρης εγκατάσταση, ενεργοποίηση & ρύθμιση του προσφερόμενου λογισμικού ώστε να καταστεί πλήρως λειτουργικό (εισαγωγή κωδικών, ρυθμίσεις, καλώδια κ.λ.π).

ΝΑΙ


Έργο ΑΝΝΑ

Μετά την ολοκλήρωση των εργασιών, θα δημιουργηθεί οπτικός δίσκος ανάκαμψης (Recovery CD ή DVD) ο οποίος θα συνοδεύει κάθε Η/Υ.

ΝΑΙ

10.9. Σταθεροί Προσωπικοί Υπολογιστές (PC) (Καλύπτει το πιλοτικό 1)


Αριθμός μονάδων. 50

Να αναφερθεί ο κατασκευαστής, το μοντέλο και η αναλυτική σύνθεση του προσφερόμενου συστήματος.

NAI

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

ΝΑΙ

Να αναφερθούν οι συνολικές και οι ελεύθερες θύρες επέκτασης (π.χ. PCI/PCI Express) της Μητρικής Κάρτας του προσφερόμενου σταθμού εργασίας.

NAI

Να είναι τύπου Small Form Factor ΠΡΟΑΙΡΕΤΙΚΟ

ΕΠΕΞΕΡΓΑΣΤΗΣ (CPU)

Να περιγραφεί ο τύπος και η αρχιτεκτονική της. ΝΑΙ

Αριθμός πυρήνων. ≥ 4

Ταχύτητα επεξεργαστή. ≥ 2.8 GHz

ΚΥΡΙΑ ΜΝΗΜΗ (RAM)

Χωρητικότητα ≥ 6GB

Η συνολική προσφερόμενη μνήμη να αποτελείται από δύο (2) τεμάχια

[πχ 4GB -> 2x2GB].ΝΑΙ

Τύπος DDR-3 ή νεότερη. ΝΑΙ

Ταχύτητα. ≥ 1333 MHz

Διάταξη. Dual-channel

ΣΚΛΗΡΟΙ ΔΙΣΚΟΙ

Τεμάχια. 2

Συνολική χωρητικότητα δίσκων. ≥ 1 TB

Ταχύτητα περιστροφής δίσκων. ≥ 7.200 rpm

Πρωτόκολλο επικοινωνίας SATA 2 ή SATA3 ή πιο σύγχρονο. ΝΑΙ

ΟΔΗΓΟΣ ΟΠΤΙΚΩΝ ΔΙΣΚΩΝ

Ανάγνωση δίσκων CD, DVD±RW. Να αναφερθούν οι ταχύτητες. ΝΑΙ


Έργο ΑΝΝΑ

Εγγραφή δίσκων CD-RW, DVD±RW. Να αναφερθούν οι ταχύτητες. ΝΑΙ

ΚΑΡΤΑ ΓΡΑΦΙΚΩΝ

Ανεξάρτητη μνήμη (όχι shared). ≥ 1 GB

Τύπος μνήμης Να αναφερθεί

ΕΠΙΚΟΙΝΩΝΙΕΣ

Να αναφερθούν αναλυτικά οι θύρες διασύνδεσης (π.χ. USB, παράλληλες, κλπ).

ΝΑΙ

Gigabit Ethernet Adapter 10/100/1000 Mbps ή 100/1000 Mbps. ≥ 1

Wireless LAN Adapter με υποστήριξη πρωτοκόλλων ΙΕΕΕ 802.11 b/g/n ή πιο σύγχρονο (ενσωματωμένο ή εξωτερικό με USB σύνδεση).

ΝΑΙ

Ενσωματωμένες Θύρες USB 2.0 ή/και USB 3.0 ή ανώτερης τεχνολογίας. ≥ 2

ΟΘΟΝΗ

Να αναφερθεί ο κατασκευαστής και το μοντέλο. ΝΑΙ

Τύπος TFT έγχρωμη. Να αναφερθεί η τεχνολογία (πχ LCD, LED). ΝΑΙ

Μέγεθος διαγωνίου (ίντσες) ≥24

Να αναφερθεί η μέγιστη υποστηριζόμενη ανάλυση. ΝΑΙ

Να αναφερθεί η αναλογία. ΝΑΙ

Θύρα σύνδεσης συμβατή με την κάρτα γραφικών. ΝΑΙ

Ένδειξη ενεργειακής απόδοσης "EnergyStar" ή άλλης ισότιμης σύμφωνα με Κοινή Υπουργική Απόφαση Δ6/Β/14826/2008 (ΦΕΚ 1122Β/17-06-2008)

ΝΑΙ

ΛΟΙΠΑ ΜΕΡΗ

Κάρτα ήχου. ΝΑΙ

Ηχεία ΝΑΙ

Τροφοδοτικό επαρκούς ισχύος. ΝΑΙ

Πληκτρολόγιο τύπου QWERTY με μόνιμη αποτύπωση Ελληνικών & Λατινικών χαρακτήρων ( ≥ 101 χαρακτήρων).

ΝΑΙ

Ποντίκι ενσύρματο, οπτικό με ροδέλα. ΝΑΙ

Δύο (02) καλώδια patch cords (τουλάχιστον CAT5E) μήκους πέντε (05) και δεκαπέντε (15) μέτρων

ΝΑΙ

ΛΕΙΤΟΥΡΓΙΚΟ ΣΥΣΤΗΜΑ

Να είναι σε παραθυρικό περιβάλλον. ΝΑΙ


Έργο ΑΝΝΑ

Να χρησιμοποιεί την Ελληνική γλώσσα. ΝΑΙ

Να είναι πλήρως συμβατό με τον προσφερόμενο εξοπλισμό. ΝΑΙ

Να υποστηρίζει την εγκατάσταση σε περιβάλλον δικτυακών ομάδων και τομέων (workgroup και domain).

ΝΑΙ

Να συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ

Να μην απαιτεί νέα ή/και ειδική εκπαίδευση των χρηστών σε σχέση με τα πακέτα εφαρμογών – λειτουργικών συστημάτων που ήδη χρησιμοποιούνται στον Φορέα (ενδεικτικά αναφέρονται ελληνικές επαγγελματικές εκδόσεις Microsoft Windows XP, Vista,7).

ΝΑΙ

ΛΟΓΙΣΜΙΚΟ ΑΥΤΟΜΑΤΙΣΜΟΥ ΓΡΑΦΕΙΟΥ

Να περιέχεται επεξεργαστής κειμένου, λογιστικό φύλλο, λογισμικό δημιουργίας παρουσιάσεων.

ΝΑΙ

Η ανακοίνωση της έκδοσής του να έχει γίνει την τελευταία τριετία από την ημερομηνία διεξαγωγής του διαγωνισμού.

ΝΑΙ

Να είναι πλήρως συμβατό με το προσφερόμενο λειτουργικού σύστημα. ΝΑΙ

Να συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ

Να χρησιμοποιεί την Ελληνική γλώσσα. ΝΑΙ

Να μην απαιτεί νέα ή/και ειδική εκπαίδευση των χρηστών σε σχέση με τα πακέτα εφαρμογών αυτοματισμού γραφείου που ήδη χρησιμοποιούνται στον Φορέα (ενδεικτικά αναφέρονται ελληνικές εκδόσεις Microsoft Office XP, 2003, 2007).

ΝΑΙ

ΛΟΙΠΟ ΛΟΓΙΣΜΙΚΟ

Εγκατεστημένο λογισμικό εγγραφής CD & DVD το οποίο θα συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ

Εγκατεστημένο Λογισμικό προστασίας από ιούς με δυνατότητα αυτόματης ανανέωσης μέσω διαδικτύου συνοδευόμενο από άδεια χρήσης (ή ανανεώσεις αδειών) για τουλάχιστον 2 έτη.

ΝΑΙ

ΓΕΝΙΚΕΣ ΑΠΑΙΤΗΣΕΙΣ ΛΟΓΙΣΜΙΚΟΥ

Πλήρης εγκατάσταση, ενεργοποίηση & ρύθμιση του προσφερόμενου λογισμικού ώστε να καταστεί πλήρως λειτουργικό (ρυθμίσεις, εισαγωγή κωδικών, καλώδια κλπ).

ΝΑΙ

Μετά την ολοκλήρωση των εργασιών, θα δημιουργηθεί οπτικός δίσκος ανάκαμψης (Recovery CD ή DVD) ο οποίος θα συνοδεύει κάθε Η/Υ.

ΝΑΙ


Έργο ΑΝΝΑ

10.10. Φορητοί Υπολογιστές (Καλύπτει το πιλοτικό 1)


Αριθμός μονάδων. 10

Να αναφερθεί ο κατασκευαστής, το μοντέλο και η αναλυτική σύνθεση του προσφερόμενου συστήματος.

NAI

Ένδειξη ενεργειακής απόδοσης "EnergyStar" ή άλλης ισότιμης σύμφωνα με Κοινή Υπουργική Απόφαση Δ6/Β/14826/2008 (ΦΕΚ 1122Β/17-06-2008)

ΝΑΙ

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

ΝΑΙ

ΕΠΕΞΕΡΓΑΣΤΗΣ (CPU)

Να περιγραφεί ο τύπος και η αρχιτεκτονική της. ΝΑΙ

Αριθμός πυρήνων επεξεργαστή (CPU). ≥ 4

Ταχύτητα επεξεργαστή. ≥ 2 GHz

ΚΥΡΙΑ ΜΝΗΜΗ (RAM)

Χωρητικότητα ≥ 4GB

Η συνολική προσφερόμενη μνήμη να αποτελείται από δύο (2) τεμάχια

[πχ 4GB -> 2x2GB].ΝΑΙ

Τύπος DDR-3 ή νεότερη. ΝΑΙ

Ταχύτητα. ≥ 1333 MHz

ΣΚΛΗΡΟΙ ΔΙΣΚΟΙ

Σκληρός Δίσκος Serial ATA. ≥ 1

Συνολική Χωρητικότητα σκληρού/ών δίσκου/ων. ≥ 500 GB

Ταχύτητα περιστροφής δίσκου/ων. ≥ 5.400 rpm

ΟΔΗΓΟΣ ΟΠΤΙΚΩΝ ΔΙΣΚΩΝ

Οπτικός Οπτικών Δίσκων με δυνατότητα ανάγνωσης δίσκων CD, DVD±RW. Να αναφερθούν οι ταχύτητες.

ΝΑΙ

ΟΘΟΝΗ

Μέγεθος διαγωνίου (ίντσες) ≥ 15,6

Να αναφερθεί η μέγιστη υποστηριζόμενη ανάλυση. ΝΑΙ

Να αναφερθεί η αναλογία της οθόνης. NAI

ΚΑΡΤΑ ΓΡΑΦΙΚΩΝ


Έργο ΑΝΝΑ

Κάρτα γραφικών με ανεξάρτητη μνήμη 1024ΜΒ τουλάχιστον. ΝΑΙ

ΕΠΙΚΟΙΝΩΝΙΕΣ

Ενσωματωμένος Gigabit Ethernet Adapter 10/100/1000 Mbps ή 100/1000 Mbps.

ΝΑΙ

Ενσωματωμένος Wireless LAN Adapter με υποστήριξη πρωτοκόλλων ΙΕΕΕ 802.11 b/g/n ή πιο σύγχρονο.

ΝΑΙ

Υποστήριξη πρωτοκόλλου Bluetooth 2.0 ΝΑΙ

ΛΟΙΠΑ ΜΕΡΗ

Πληκτρολόγιο τύπου QWERTY, με μόνιμη αποτύπωση των ελληνικών και λατινικών χαρακτήρων σε κάθε πλήκτρο.

ΝΑΙ

Συσκευή κατάδειξης (touchpad) ενσωματωμένη στο laptop. ΝΑΙ

Ενσωματωμένη κάμερα. ΝΑΙ

Ενσωματωμένο μικρόφωνο. ΝΑΙ

Ποντίκι ενσύρματο, οπτικό με ροδέλα. ΝΑΙ

Βάρος (με μπαταρία). ≤ 3 κιλά

Τύπος μπαταρίας Lithium-ion (Li-Ion). ΝΑΙ

Εφεδρική μπαταρία ΝΑΙ

Ενσωματωμένο ή εξωτερικό Card Reader ΝΑΙ

Υποστηριζόμενοι τύποι καρτών για το Card Reader Να αναφερθούν

ΛΕΙΤΟΥΡΓΙΚΟ ΣΥΣΤΗΜΑ

Εγκατεστημένο λειτουργικό σύστημα με παραθυρικό περιβάλλον το οποίο χρησιμοποιεί την ελληνική γλώσσα.

ΝΑΙ

Το λειτουργικό σύστημα να είναι πλήρως συμβατό με τον προσφερόμενο εξοπλισμό και να συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ

Το λειτουργικό σύστημα να υποστηρίζει την εγκατάσταση σε περιβάλλον δικτυακών ομάδων και τομέων (workgroup και domain).

ΝΑΙ

Το λειτουργικό σύστημα να μην απαιτεί νέα ή/και ειδική εκπαίδευση των χρηστών σε σχέση με τα πακέτα εφαρμογών – λειτουργικών συστημάτων που ήδη χρησιμοποιούνται στον Φορέα (ενδεικτικά αναφέρονται ελληνικές επαγγελματικές εκδόσεις Microsoft Windows XP, Vista,7).

ΝΑΙ

ΛΟΓΙΣΜΙΚΟ ΑΥΤΟΜΑΤΙΣΜΟΥ ΓΡΑΦΕΙΟΥ

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

ΝΑΙ


Έργο ΑΝΝΑ

Το λογισμικό αυτοματισμού γραφείου να είναι πλήρως συμβατό με το προσφερόμενο λειτουργικού σύστημα και να συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ

Το λογισμικό αυτοματισμού γραφείου να μην απαιτεί νέα ή/και ειδική εκπαίδευση των χρηστών σε σχέση με τα πακέτα εφαρμογών αυτοματισμού γραφείου που ήδη χρησιμοποιούνται στον Φορέα (ενδεικτικά αναφέρονται ελληνικές εκδόσεις Microsoft Office XP, 2003, 2007).

ΝΑΙ

ΛΟΙΠΟ ΛΟΓΙΣΜΙΚΟ

Εγκατεστημένο λογισμικό εγγραφής CD & DVD το οποίο θα συνοδεύεται από όλες τις απαιτούμενες άδειες χωρίς χρονικούς περιορισμούς (time limitations).

ΝΑΙ


ΝΑΙ

ΓΕΝΙΚΕΣ ΑΠΑΙΤΗΣΕΙΣ ΛΟΓΙΣΜΙΚΟΥ

Πλήρης εγκατάσταση, ενεργοποίηση & ρύθμιση του προσφερόμενου λογισμικού ώστε να καταστεί πλήρως λειτουργικό (εισαγωγή κωδικών, ρυθμίσεις, καλώδια κλπ).

ΝΑΙ

ΔΙΑΦΟΡΑ

Τσάντα μεταφοράς κατάλληλη για τον προσφερόμενο φορητό Η/Υ. ΝΑΙ

Δύο (02) καλώδια patch cords (τουλάχιστον CAT5E) μήκους πέντε (05) και δεκαπέντε (15) μέτρων

ΝΑΙ

10.11. Tablets (Καλύπτει το πιλοτικό 1)

Μοντέλο-Κατασκευαστής Να αναφερθεί

Αριθμός Μονάδων 12

Επεξεργαστής

Αριθμός πυρήνων >=4

Ταχύτητα κάθε πυρήνα >= 1,2 GHz

Κύρια Μνήμη (RAM)

Χωρητικότητα >=1GB

Τύπος DDR3

Μνήμη (Εσωτερική χωρητικότητα αποθήκευσης)

eMMC socket >=1


Έργο ΑΝΝΑ

Χωρητικότητα eMMC >=16GB

Αποθήκευση με εξωτερικά μέσα ΠΡΟΑΙΡΕΤΙΚΟ

Εξωτερική κάρτα επέκτασης μνήμης με τη μέγιστη υποστηριζόμενη χωρητικότητα της συσκευής


Κάρτα γραφικών Ενσωματωμένη ΝΑΙ

Ήχος

Έξοδος ήχου Υποδοχή ήχου 3,5 χιλ.

Ενσωματωμένα ηχεία ΝΑΙ

Ενσωματωμένο Μικρόφωνο ΝΑΙ

Δίαυλοι επικοινωνίας

Ενσωματωμένο 3G ή 4G ΝΑΙ

Ενσωματωμένος Wireless LAN AdapterΥποστήριξη πρωτοκόλλων ΙΕΕΕ 802.11 b/g/n ή πιο σύγχρονο

Θύρες USB 2.0 ή micro USB >=1

Θύρα BluetoothΥποστήριξη πρωτοκόλλου Bluetooth >=4.0

Ενσωματωμένη Κάμερα Web

Εμπρόσθια

Οπίσθια

Ανάλυση >= 1,0 MPixels

Ανάλυση >= 5 MPixels

Πληκτρολόγιο Πρόσθετο με εξωτερική σύνδεση, ενσύρματη ή ασύρματη. Τύπου QWERTY με μόνιμη αποτύπωση Ελληνικών & Λατινικών χαρακτήρων

Οθόνη

Τύπος Multi-Touch (IPS ή TFT LCD)

Μέγεθος διαγωνίου >=9 ίντσες

Φυσική ανάλυση >= 1980x1080 εικονοστοιχεία

Βάρος <= 800 gr

Διάρκεια ζωής μπαταρίας >= 450 min

Μπαταρία >=4300 mAh

Παρελκόμενα

Θήκη μεταφοράς τύπου Φακέλου 1

Βάση στήριξης 1

Τροφοδοτικό AC (Συμβατό με tablet) 1


Έργο ΑΝΝΑ

Στερεοφωνικά ακουστικά 3,5 mm 1

User Manual 1

Service Manual (σε έντυπη ή ηλεκτρονική μορφή) 1

Προστατευτικές Μεμβράνες Οθόνης 3

Μετατροπέας micro USB σε USB 2.0 (εάν δεν διαθέτει θύρα USB 2.0) ΝΑΙ

Λειτουργικό Σύστημα & Λοιπό Λογισμικό

Εγκατεστημένο Λειτουργικό Σύστημα

Κατάλληλο λειτουργικό σύστημα με τα ακόλουθα χαρακτηριστικά:

- Να είναι σε παραθυρικό περιβάλλον.

- Να χρησιμοποιεί την Ελληνική γλώσσα.

- Να είναι πλήρως συμβατό με τον προσφερόμενο εξοπλισμό.


Η ανακοίνωση της έκδοσής του να έχει γίνει την τελευταία διετία από την ημερομηνία διεξαγωγής του διαγωνισμού.

Να παρασχεθούν τρεις ομάδες συσκευών με διαφορετικό λειτουργικό σύστημα η κάθε μία.

Εγκατεστημένο Πακέτο Αυτοματισμού Γραφείου Κατάλληλο λογισμικό αυτοματισμού γραφείου με τα ακόλουθα χαρακτηριστικά:

- Να περιέχεται επεξεργαστής κειμένου, λογιστικό φύλλο, λογισμικό δημιουργίας παρουσιάσεων.

- Η ανακοίνωση της έκδοσής του να έχει γίνει την τελευταία τριετία από την ημερομηνία διεξαγωγής του διαγωνισμού.

- Να είναι πλήρως συμβατό με το


Έργο ΑΝΝΑ

προσφερόμενο λειτουργικού σύστημα.


- Να χρησιμοποιεί την Ελληνική γλώσσα.



Πλήρης εγκατάσταση, ενεργοποίηση & ρύθμιση του προσφερόμενου λογισμικού ώστε να καταστεί πλήρως λειτουργικό (εισαγωγή κωδικών, ρυθμίσεις, κ.λ.π).

ΝΑΙ

10.12. Γενικές Απαιτήσεις

Όλος ο βασικός εξοπλισμός (υλικό και λογισμικό) πρέπει να εγκατασταθεί και να τεθεί σε πλήρη λειτουργία στο κεντρικό κτίριο του Λ.Σ. –ΕΛ.ΑΚΤ.

ΝΑΙ

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

ΝΑΙ

Ο ανάδοχος θα πρέπει να προσφέρει επίσης δωρεάν όλο τον επιπλέον απαιτούμενο παθητικό εξοπλισμό που θα απαιτηθεί για την εγκατάσταση και πλήρη ενεργοποίηση του προσφερόμενου εξοπλισμού.

ΝΑΙ

Ειδικότερα για τον εξοπλισμό του παρόντος κεφαλαίου ο ανάδοχος θα πρέπει να αναλάβει τις ακόλουθες υποχρεώσεις:

Αποσυσκευασία και επιθεώρηση του εξοπλισμού στο χώρο εγκατάστασης παρουσία εκπροσώπων του Φορέα προκειμένου να επαληθευτεί ότι τα παραδοθέντα υλικά ταυτίζονται με τα παραγγελθέντα.

ΝΑΙ

Συναρμολόγηση των λειτουργικών μερών του σύμφωνα με τις προδιαγραφές του κατασκευαστή.

ΝΑΙ

Εγκατάσταση του εξοπλισμού σε rack και του τυχόν συνοδευτικού εξοπλισμού.

ΝΑΙ

Εφαρμογή των πλέον πρόσφατων αναβαθμίσεων firmware για όλα τα λειτουργικά μέρη του εξοπλισμού.

ΝΑΙ


Έργο ΑΝΝΑ

Πραγματοποίηση παραμετροποίησης RAID στο Storage Area Network ΝΑΙ

Επίδειξη και επιβεβαίωση ότι όλες οι συνδέσεις είναι ασφαλείς και σωστές.

ΝΑΙ

Επίδειξη και επιβεβαίωση εκκίνησης των servers, επιτυχή σύνδεση τους στο LAN και SAN.

ΝΑΙ

Διευκρινίζεται ότι το υφιστάμενο Data Center του ΑΛΣ-ΕΛ.ΑΚΤ. διαθέτει μονοφασική παροχή ρεύματος. Αν ο υπό προμήθεια εξοπλισμός απαιτεί την ύπαρξη τριφασικής υποδοχής, οι τροποποιήσεις των ηλεκτρολογικών εγκαταστάσεων θα γίνουν με μέριμνα, ευθύνη και δαπάνη του Αναδόχου.

ΝΑΙ

Υποχρεωτική σήμανση CE NAI


Έργο ΑΝΝΑ

ΚΕΦΑΛΑΙΟ 11: Γενικοί Όροι

11.1. Μελέτη Εφαρμογής

Ο Ανάδοχος υποχρεούται στην εκπόνηση και υποβολή μελέτης εφαρμογής, σύμφωνα με τους χρόνους που παρατίθενται στην Παρ. 11.6 Χρονοδιάγραμμα Έργου. Για το σκοπό αυτό, μετά την υπογραφή της Σύμβασης, θα πραγματοποιούνται τακτικές συσκέψεις με την επισπεύδουσα Υπηρεσία (ΔΙΠΘΑΚ), τη συναρμόδια Υπηρεσία (ΔΙΠΛΕΠ) και την Επιτροπή Παρακολούθησης, η οποία θα συσταθεί με μέριμνα της Διεύθυνσης Προμηθειών.

Η μελέτη θα ενημερώνεται σε κάθε φάση εξέλιξης του έργου με ευθύνη και μέριμνα του Αναδόχου.

Στη μελέτη θα περιλαμβάνονται ενδεικτικά τουλάχιστον οι ακόλουθες ενότητες:

1. Γενική Αρχιτεκτονική συστήματος (βλ. Κεφ. 2 των Τεχνικών Προδιαγραφών )

2. Ασφάλεια πληροφοριακού συστήματος - Ανάλυση μεθόδων προστασίας προσωπικών δεδομένων (βλ. Παρ. 2.2 των Τεχνικών Προδιαγραφών ) Διαχείριση ρόλων χρηστών (Διαχειριστές συστήματος, Διαχειριστές εφαρμογής, Πολίτες, Χρήστες API, Χρήστες Φορέων) ) – Πολιτική Δικαιωμάτων – Διαδικασία Δημιουργίας Χρηστών – Ασφάλεια Κωδικών (βλ. Κεφ 4. των Τεχνικών Προδιαγραφών )

3. Πιλοτικό έργο 1: FrontOffice Γενική Αρχιτεκτονική, Λειτουργικές απαιτήσεις GUI, Εισαγωγή Δεδομένων, Ροή Καταχώρησης, Ταχύτητα Απόκρισης (βλ. Κεφ.5 των Τεχνικών Προδιαγραφών )

4. Πιλοτικό Έργο 2: MidOffice: Γενική Αρχιτεκτονική, Χειρισμός Μηνυμάτων, Εφεδρικότητα, Μεθοδολογία Backup , Έλεγχοι Μηνυμάτων, Back ends, Χειρισμός Λαθών, Ροή εργασίας χειρισμού σφαλμάτων (βλ. Κεφ.6 των Τεχνικών Προδιαγραφών )

5. Πιλοτικό Έργο 3: BackOffice: Γενική Αρχιτεκτονική, Υλοποίηση διασυνδέσεων με τρίτα πληροφοριακά συστήματα (βλ. Κεφ. 7 των Τεχνικών Προδιαγραφών )

6. Πιλοτικό Έργο 4: Διεπαφή Ανάκτησης Δεδομένων. Ασφάλεια, Αναφορές, Μηχανισμός διαχείρισης αιτήσεων και προβλημάτων, Επιπλέον λειτουργικότητα για το SafeSeaNet, Παρουσίαση Πληροφοριών- Στατιστικών (βλ. Κεφ. 8 των Τεχνικών Προδιαγραφών )

7. Υποσύστημα Διαχείρισης & Εποπτείας (βλ. Κεφ 9 των Τεχνικών Προδιαγραφών)

8. Εξοπλισμός (βλ. Κεφ. 10 των Τεχνικών Προδιαγραφών)

9. Πολιτική – Μεθοδολογία – Εργαλεία και διαχείριση ενημερώσεων λογισμικού

10. Πρόγραμμα συντήρησης

11. Μεθοδολογία υποστήριξης και συντήρησης

12. Εκπαίδευση

13. Μεθοδολογία δοκιμαστικής λειτουργίας – Σενάρια Δοκιμών

14. Χρονοδιάγραμμα Έργου


Έργο ΑΝΝΑ

Η έγκριση της εν λόγω μελέτης από τα αρμόδια όργανα και Υπηρεσίες του ΑΛΣ-ΕΛΑΚΤ αποτελεί προϋπόθεση για την έναρξη των εργασιών υλοποίησης του έργου από τον Ανάδοχο. Στην περίπτωση που υπάρχουν παρατηρήσεις από πλευράς του ΑΛΣ-ΕΛΑΚΤ επί της υποβληθείσας μελέτης, οι απαραίτητες διορθωτικές ενέργειες θα πρέπει να ακολουθούν τους χρόνους που παρατίθενται στην Παρ. 11.6 Χρονοδιάγραμμα Έργου.

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

11.2. Παράδοση

Το έργο θα παραδοθεί σε πλήρη λειτουργία εντός έξι (06) μηνών από την έγκριση της μελέτης εφαρμογής, σύμφωνα με τους χρόνους που παρατίθενται στην Παρ. 11.6 (Χρονοδιάγραμμα Έργου).

Τόπος παράδοσης ορίζεται η έδρα του ΑΛΣ-ΕΛΑΚΤ (Ακτή Βασιλειάδη, Λιμένας Πειραιώς).

Με την ολοκλήρωση της παράδοσης, ο Ανάδοχος θα πρέπει να καταθέσει στην επισπεύδουσα Υπηρεσία του ΑΛΣ-ΕΛΑΚΤ τα εξής:

Α. Τον πηγαίο κώδικα υλοποίησης της εφαρμογής, μέσω του οποίου θα παρέχεται η δυνατότητα στο χρήστη επαναπαραμετροποίησης, τροποποίησης ή επέκταση αυτού ανά πάσα στιγμή χωρίς καμία απαίτηση αδείας ή περιορισμού σε επίπεδο λογισμικού, σύμφωνα και με τα οριζόμενα στην παρ. 4 του Άρθρου 19 του Ν. 3979/2011 περί Ηλεκτρονικής Διακυβέρνησης.

Β. Τεκμηρίωση του συστήματος, αναλυτική περιγραφή της ΒΔ και των εφαρμογών

Γ. Μελέτη εκτίμησης τρωτότητας του συστήματος (Vulnerability Assessment), όπως αυτή θα έχει επικαιροποιηθεί μετά τη διενέργεια των δοκιμών.

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

Ε. Εκτός από το παραγωγικό θα παραδοθεί επιπλέον UAT, staging & development περιβάλλον

ΣΤ. Όλα τα εργαλεία με τις κατάλληλες άδειες για τυχόν επεμβάσεις (πχ προσθήκη νέων λειτουργιών, διόρθωση λειτουργικότητας λόγω νέων αναγκών κοκ) στο υπάρχον σύστημα ανάπτυξης από τα στελέχη των Φορέων καθώς και αναλυτικό workflow για εύκολο deployment αρχικά στο τεστ περιβάλλον προς έλεγχο και από εκεί στην παραγωγή.

Ζ. Τεχνικά εγχειρίδια του συστήματος (system manuals) και των εργαλείων διαχείρισης, λεπτομερή εγχειρίδια λειτουργίας (operation manuals) και υποστήριξης χρηστών (user manuals). Τα εγχειρίδια λειτουργίας και υποστήριξης χρηστών απαιτείται να έχουν συνταχθεί στην Ελληνική γλώσσα. Τα τεχνικά εγχειρίδια και το λοιπό τεκμηριωτικό υλικό δύναται να είναι είτε στην Ελληνική είτε στην Αγγλική γλώσσα. Επιπρόσθετα θα παρασχεθούν εγχειρίδια/οδηγοί χρήσης του πληροφοριακού συστήματος, στην ελληνική


Έργο ΑΝΝΑ

και αγγλική γλώσσα, για τους πολίτες που είναι υπόχρεοι σε υποβολή των αναφορών που προβλέπονται από την κοινοτική οδηγία 2010/65.

Εκτός των ανωτέρω, σε κάθε περίπτωση, στα παραδοτέα περιλαμβάνονται και όλα τα αναφερόμενα στο παρόν τεύχος τεχνικών προδιαγραφών.

11.3. Εκπαίδευση

Με την παράδοση του έργου και σύμφωνα με το χρονοδιάγραμμα της Παρ. 11.6, θα ξεκινήσει η παροχή των υπηρεσιών εκπαίδευσης σε τριάντα (30) στελέχη του Λ.Σ.-ΕΛ.ΑΚΤ, εκ των οποίων ενδεχομένως τα δέκα (10) να προέρχονται από Περιφερειακές Υπηρεσίες. Στην περίπτωση αυτή ο Ανάδοχος θα καλύψει τις δαπάνες μετακίνησης και διαμονής. Η εκπαίδευση θα έχει διάρκεια τουλάχιστον δεκαπέντε (15) ημερών με οκτώ (08) ώρες διδασκαλίας ανά ημέρα.

Οι εν λόγω υπηρεσίες θα πρέπει κατ’ ελάχιστον να αφορούν θεωρητική και πρακτική εκπαίδευση σε επίπεδο χρήστη, σε επίπεδο διαχειριστή και σε επίπεδο τεχνικής υποστήριξης του συστήματος.

Ιδιαίτερα επισημαίνεται ότι, για την εκπαίδευση επιπέδου χρήστη και διαχειριστή, θα χρησιμοποιηθεί, με μέριμνα του Αναδόχου, εκπαιδευτική πλατφόρμα του συστήματος, η λειτουργικότητα της οποίας θα είναι πανομοιότυπη με το παραγωγικό περιβάλλον.

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

Μετά το πέρας της εκπαίδευσης, ο Ανάδοχος θα χορηγήσει σε κάθε εκπαιδευόμενο κατάλληλα πιστοποιητικά εκπαίδευσης.

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

11.4. Δοκιμές

Μετά την ολοκλήρωση της εκπαίδευσης, θα υπάρξει υποχρεωτική περίοδος δοκιμαστικής λειτουργίας του συστήματος, διάρκειας τουλάχιστον τριάντα (30) ημερών, με χρόνο ημερήσιας λειτουργίας είκοσι τεσσάρων (24) ωρών. Κατά τη διάρκεια της περιόδου αυτής, ο Ανάδοχος υποχρεούται, σε συνεργασία με τους υπευθύνους του Α.Λ.Σ.-ΕΛ.ΑΚΤ. (Επιτροπή Παρακολούθησης, Επιτροπή Παραλαβής, επισπεύδουσα Υπηρεσία ΔΙΠΘΑΚ, συναρμόδια Υπηρεσία ΔΙΠΛΕΠ και προαιρετικά τα στελέχη ΛΣ-ΕΛΑΚΤ που εκπαιδεύτηκαν με τους όρους της Παρ. 11.3), να προβεί στην εκτέλεση δοκιμών, σύμφωνα με τα οριζόμενα στην εγκεκριμένη μελέτη εφαρμογής. Οι εν λόγω δοκιμές έχουν ως στόχο να διαπιστωθεί η απόλυτα εύρυθμη λειτουργία και καλή συνεργασία των εφαρμογών του συστήματος, υπό συνθήκες πλήρους παραγωγικής λειτουργίας.


Έργο ΑΝΝΑ

Η επίδοση του συστήματος πρέπει να επιτυγχάνει τους απαιτούμενους χρόνους απόκρισης στο FO (βλ. Παρ.5.5 ). Για τη μέτρηση των επιδόσεων αυτών ο Ανάδοχος θα πρέπει να έχει προτείνει τα κατάλληλα προγράμματα λογισμικού, κατά την υποβολή της μελέτης εφαρμογής, τα οποία θα χρησιμοποιηθούν κατά την εκτέλεση των σχετικών δοκιμών αλλά και κατά τη διάρκεια ισχύος της σύμβασης. Ιδιαίτερα κατά τη διάρκεια των δοκιμών, ο Ανάδοχος θα πρέπει να υποβάλει το σύστημα σε stress test με εξομοίωση φόρτου, σύμφωνα με τη μεθοδολογία τον τρόπο υλοποίησης που έχει προτείνει στη μελέτη εφαρμογής, κατά τη διάρκεια του οποίου θα πρέπει να τηρούνται οι προβλεπόμενες μετρικές της διαθεσιμότητας.

Εάν κατά τη διάρκεια της δοκιμαστικής λειτουργίας το σύστημα παρουσιάσει αποκλίσεις από τα οριζόμενα στην τεχνική προδιαγραφή ή/και την τεχνική προσφορά ή/και τη μελέτη εφαρμογής, τότε θα ακολουθήσουν οι απαραίτητες διορθωτικές ενέργειες εντός του χρόνου που προβλέπεται στην Παρ. 11.6 Χρονοδιάγραμμα Έργου.

11.5. Παραλαβή έργου

Η οριστική ποσοτική και ποιοτική παραλαβή του έργου θα ολοκληρωθεί το αργότερο εντός δέκα (10) ημερών από την επιτυχή ολοκλήρωση των δοκιμαστικών ελέγχων. Διευκρινίζεται ότι, η εκπαίδευση αποτελεί παραδοτέα υπηρεσία, ως εκ τούτου θα συμπεριλαμβάνεται στο σχετικό πρωτόκολλο.

11.6. Χρονοδιάγραμμα Έργου

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

Υποβολή Μελέτης Εφαρμογής: Το αργότερο εντός τριάντα (30) ημερών από την υπογραφή της Σύμβασης. Η μελέτη εφαρμογής θα περιλαμβάνει κατ’ ελάχιστο τα αναφερόμενα του Κεφ. 11.1.

Έγκριση Μελέτης Εφαρμογής: Το αργότερο εντός είκοσι (20) ημερών από την υποβολή της. Η έγκριση θα γίνει από την αρμόδια Επιτροπή Παρακολούθησης Α.Λ.Σ.- ΕΛ.ΑΚΤ σε συνεργασία με την επισπεύδουσα Υπηρεσία του έργου (ΔΙΠΘΑΚ) και με την κατά λόγο αρμοδιότητας συνδρομή της συναρμόδιας Υπηρεσίας (ΔΙΠΛΕΠ).

Χρόνος διορθωτικών ενεργειών: Στην περίπτωση που υπάρχουν παρατηρήσεις από την πλευρά του ΛΣ-ΕΛΑΚΤ επί ζητημάτων της μελέτης εφαρμογής, η Επιτροπή Παρακολούθησης θα ενημερώνει εγγράφως τον Ανάδοχο (σε κάθε περίπτωση όχι πέραν του χρόνου των είκοσι (20) ημερών της προηγούμενης παραγράφου). Ο Ανάδοχος θα προβαίνει στις απαραίτητες διορθωτικές ενέργειες, οπότε θα υποβάλλει εκ νέου τη μελέτη για έγκριση, το αργότερο εντός (10) ημερών από την ως άνω έγγραφη ειδοποίησή του. Η έγκριση της μελέτης, στην περίπτωση αυτή, δε θα ξεπερνά χρονικά τις δέκα (10) ημέρες. Η διαδικασία επανυποβολής μπορεί να πραγματοποιηθεί μέχρι δύο (2) φορές.

Χρόνος Παράδοσης: Το σύστημα θα παραδοθεί σε πλήρη λειτουργία το αργότερο εντός έξι (06) μηνών από την έγκριση της μελέτης εφαρμογής. Ιδιαίτερα για το χρόνο παράδοσης των έξι (06) μηνών, ο υποψήφιος ανάδοχος θα πρέπει να αναλύσει περαιτέρω στην τεχνική του προσφορά και ακολούθως να εξειδικεύσει στην μελέτη εφαρμογής, τη μεθοδολογία


Έργο ΑΝΝΑ

υλοποίησης του έργου με σαφείς αναφορές στο χρόνο ολοκλήρωσης κάθε επιμέρους φάσης με τις απαιτούμενες προϋποθέσεις υλοποίησης και τα αντίστοιχα παραδοτέα κάθε φάσης. Επισημαίνεται ότι, δεδομένης της κοινοτικής υποχρέωσης περί υλοποίησης του έργου ΑΝΝΑ από τα κ-μ μέχρι το τέλος του 2015 και έναρξης λειτουργίας της ενιαίας ναυτιλιακής θυρίδας την 1η Ιουνίου 2015, το προτεινόμενο χρονοδιάγραμμα των έξι (06) μηνών θα πρέπει να καταρτιστεί έτσι ώστε να έχει επιτευχθεί η υλοποίηση ικανού μέρους της λειτουργικότητας του συστήματος έως την 01-06-2015. Σε κάθε περίπτωση, το τελικό επιμέρους χρονοδιάγραμμα των έξι (06) μηνών θα καθοριστεί κατά την υποβολή της μελέτης εφαρμογής και για την εφαρμογή του πρέπει να τύχει της έγκρισης του Φορέα, σύμφωνα με τα αναφερόμενα της Παρ. 11.1

Χρόνος Εκπαίδευσης: Θα ολοκληρωθεί το αργότερο εντός δεκαπέντε (15) ημερών από την παράδοση του συστήματος.

Χρόνος δοκιμών: Οι δοκιμαστικοί έλεγχοι της λειτουργίας του συστήματος θα ολοκληρωθούν το αργότερο εντός τριάντα (30) ημερών από την ολοκλήρωση της παράδοσης του συστήματος και της παροχής των υπηρεσιών εκπαίδευσης, εφόσον δεν υπάρξουν δυσλειτουργίες. Στην περίπτωση που το σύστημα παρουσιάσει αποκλίσεις από τα οριζόμενα στην τεχνική προδιαγραφή ή/και την τεχνική προσφορά ή/και τη μελέτη εφαρμογής, τότε η Επιτροπή Παρακολούθησης ενημερώνει αμελλητί και εγγράφως τον Ανάδοχο (σε κάθε περίπτωση εντός του χρόνου των τριάντα ημερών). Ο Ανάδοχος οφείλει να προβεί άμεσα και σε χρονικό διάστημα που δε θα ξεπερνά τις δέκα (10) ημέρες από την έγγραφη ενημέρωσή του, σε κατάλληλες διορθωτικές ενέργειες. Οι δοκιμές επαναλαμβάνονται κατά την κρίση της Επιτροπής Παρακολούθησης για χρονικό διάστημα το πολύ δέκα (10) ημερών. Η διαδικασία επαναληπτικών δοκιμών μπορεί να πραγματοποιηθεί μέχρι δύο (02) φορές.

Χρόνος παραλαβής: Το αργότερο εντός δέκα (10) ημερών από το πέρας των δοκιμών.

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

11.7. Παρακολούθηση Έργου

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

11.8. Εγγύηση, Συντήρηση, Τεχνική Υποστήριξη


Έργο ΑΝΝΑ

11.8.1. Εγγύηση Καλής Λειτουργίας

Ο Ανάδοχος αναλαμβάνει την υποχρέωση διασφάλισης της καλής λειτουργίας του συνόλου του προσφερόμενου συστήματος (εξοπλισμού και λογισμικού) για χρονική περίοδο που θα αναφέρεται ρητά στην τεχνική προσφορά του, η οποία δεν μπορεί να είναι μικρότερη των δύο (02) συνεχών ετών (24 μηνών). Κατά τη χρονική αυτή περίοδο, η διασφάλιση της καλής λειτουργίας του συστήματος θα προσφερθεί χωρίς κανένα κόστος για το ΛΣ-ΕΛ.ΑΚΤ με τη μορφή εγγύησης και δωρεάν συντήρησης - τεχνικής υποστήριξης τόσο για το υλισμικό (hardware) όσο και για το λογισμικό (software). Η ανωτέρω χρονική περίοδος αρχίζει από την επόμενη της ημερομηνίας του πρωτοκόλλου οριστικής ποσοτικής και ποιοτικής παραλαβής του έργου.

Ο Ανάδοχος υποχρεούται, με την οριστική ποσοτική και ποιοτική παραλαβή της προμήθειας, να καταθέσει εγγυητική επιστολή καλής λειτουργίας , ποσοστού 5% επί της καθαρής συμβατικής αξίας, με χρόνο ισχύος κατά τρεις (03) μήνες μεγαλύτερο, από τον οριζόμενο στη Σύμβαση χρόνο εγγύησης καλής λειτουργίας.

Η διασφάλιση της καλής λειτουργίας του εξοπλισμού καλύπτει την πλήρη αποκατάσταση κάθε βλάβης ή/και ανωμαλίας που δεν οφείλεται σε κακή χρήση του από το προσωπικό του ΛΣ-ΕΛ.ΑΚΤ ή σε εξωτερικούς αστάθμητους παράγοντες (σεισμούς, πλημμύρες κλπ). Τα απαραίτητα για όλες τις περιπτώσεις υλικά και ανταλλακτικά θα βαρύνουν αποκλειστικά τον Ανάδοχο. Τα μηχανικά και ηλεκτρονικά μέρη των μονάδων (δίσκοι, κλπ.) δεν θεωρούνται αναλώσιμα υλικά. Ο Ανάδοχος υποχρεούται στην αντικατάσταση κάθε μονάδας εξοπλισμού ή τμήματος αυτής, όταν η επισκευή τους δεν είναι τεχνικά εφικτή. Στην περίπτωση αυτή, τα ανταλλακτικά που τυχόν απαιτηθούν θα είναι καινούρια και αμεταχείριστα ενώ τα προς αντικατάσταση εξαρτήματα θα επιστρέφονται στον Ανάδοχο μετά την αντικατάστασή τους.

Η αποκατάσταση των προβλημάτων του συστήματος γίνεται με τη μετάβαση τεχνικών του Αναδόχου στους χώρους που είναι εγκατεστημένος ο εξοπλισμός (on site). Τυχόν έξοδα μετακίνησης και διαμονής των τεχνικών βαρύνουν αποκλειστικά τον Ανάδοχο. Το ΛΣ-ΕΛ.ΑΚΤ μπορεί να αποδεχθεί ισοδύναμες εναλλακτικές λύσεις (π.χ. να υπάρχει ένα ή περισσότερα συστήματα διαθέσιμα στις εγκαταστάσεις του Αναδόχου και με μέριμνα του ιδίου, να εγκατασταθούν προσωρινά σε αντικατάσταση αυτών που έχουν υποστεί βλάβη) υπό την προϋπόθεση ότι με τις λύσεις αυτές δεν θα υπάρξει καμιά επίπτωση στην εξυπηρέτηση των τελικών χρηστών. Επίσης είναι αποδεκτή από το ΛΣ-ΕΛΑΚΤ η επισκευή βλαβών λογισμικού μέσω δικτύου (remote), υπό την προϋπόθεση ότι δεν υπάρχουν επιπτώσεις στην ασφάλεια του συστήματος. Σε όλες τις περιπτώσεις, πάσης φύσεως δαπάνες για την επαναφορά του συστήματος στην κανονική κατάσταση λειτουργίας του, συμπεριλαμβανομένων των μεθόδων τυχόν εξάρμοσης, συσκευασίας, μεταφορικών και ασφαλίστρων τόσο των ελαττωματικών εξαρτημάτων όσο και των προς αντικατάσταση ή επισκευή ειδών, βαρύνουν τον Ανάδοχο .

Οι υποχρεώσεις του Αναδόχου όσον αφορά τους χρόνους αποκατάστασης προβλημάτων περιγράφονται αναλυτικά σε επόμενες παραγράφους.

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


Έργο ΑΝΝΑ

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

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

11.8.2. Προληπτική Συντήρηση

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

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

Η πραγματοποίηση των εργασιών προληπτικής συντήρησης (ακριβής ημερομηνία και ώρα) θα καθορίζεται σε συνεργασία του Αναδόχου και των αρμόδιων στελεχών του ΛΣ-ΕΛ.ΑΚΤ, ώστε να πραγματοποιείται υπό την επίβλεψη αρμόδιου προσωπικού του Φορέα και η συχνότητά τους δεν θα είναι μικρότερη από μία (01) φορά κάθε τέσσερις (04) μήνες. Κατά την πραγματοποίηση αυτών των εργασιών ο Ανάδοχος οφείλει να παρέχει πρακτική εκπαίδευση (on-the-job training) καθώς και μεταφορά τεχνογνωσίας στο εξειδικευμένο προσωπικό του Φορέα, με στόχο την πλήρη αξιοποίηση του υλικού και του λογισμικού. Στο πλαίσιο των υποχρεώσεών του, ο Ανάδοχος οφείλει να παρέχει κατάλληλες τεχνικές και οργανωτικές συμβουλές, μέσω τηλεφώνου ή e-mail, στο αρμόδιο προσωπικό του ΛΣ-ΕΛ.ΑΚΤ, σχετικά με τις τεχνολογίες και τις ρυθμίσεις-παραμετροποιήσεις που έχουν εφαρμοστεί στο σύστημα και να προτείνει στον Φορέα τρόπους επέκτασης ή αναβάθμισης του εξοπλισμού.

Μετά το πέρας της προγραμματισμένης προληπτικής συντήρησης, ο Ανάδοχος θα υποβάλλει: (i) Αναλυτική Καταγραφή Πεπραγμένων Συντήρησης, (ii) Λίστα ανταλλακτικών και προσδιορισμός αναλωσίμων υλικών που τυχόν απαιτήθηκαν, (iii) Τεκμηρίωση τυχόν πρόσθετων προσαρμογών και παραμετροποιήσεων σε εξοπλισμό και λογισμικό, (iv) Παράδοση αντιτύπων όλων των μεταβολών ή επανεκδόσεων ή τροποποιήσεων των εγχειριδίων του εξοπλισμού ή/και του λογισμικού, στις περιπτώσεις που απαιτείται, (v) Τεκμηρίωση τυχόν εγκατάστασης νέων εκδόσεων λογισμικό.

11.8.3. Τεχνική Υποστήριξη

Οι Υπηρεσίες Τεχνικής Υποστήριξης θα παρέχονται αδαπάνως για το Φορέα για το διάστημα της προσφερόμενης χρονικής περιόδου διασφάλισης καλής λειτουργίας.

Α. Μέγιστος χρόνος αποκατάστασης προβλημάτων - Διαθεσιμότητα Συστήματος


Έργο ΑΝΝΑ

Ο μέγιστος χρόνος αποκατάστασης προβλημάτων θα περιγράφεται αναλυτικά στην τεχνική προσφορά του υποψήφιου Αναδόχου, στην οποία θα περιλαμβάνεται σχετικός πίνακας με τη δομή και τη γραμμογράφηση του Πίνακα 1 που ακολουθεί και δεν μπορεί να υπερβαίνει τις τιμές που αναφέρονται σε αυτόν. Κατά την διάρκεια του χρόνου εγγύησης καλής λειτουργίας αν ο μέγιστος χρόνος αποκατάστασης προβλημάτων είναι μεγαλύτερος από τον αναγραφόμενο στον προαναφερθέν πίνακα θα υπάρξει σχετική ρήτρα επί της εγγυητικής επιστολής καλής λειτουργίας.

Κ.Ω.Κ. (Κανονικές Ώρες Κάλυψης): Είναι το χρονικό διάστημα από 08.00 έως 16.00 για τις εργάσιμες ημέρες.

Ε.Ω.Κ. (Επιπλέον Ώρες Κάλυψης): Είναι το χρονικό διάστημα που δεν θεωρείται Κ.Ω.Κ.

Υπηρεσίες του ΑΛΣ-ΕΛΑΚΤ

Μέγιστος Χρόνος

Απόκρισης

(Από την αναγγελία βλάβης)

Μέγιστος Χρόνος

Αποκατάστασης Βλαβών

Βλάβες που αναγγέλλονται εντός Κ.Ω.Κ.

Βλάβες που αναγγέλλοντ

αι εντός Ε.Ω.Κ.

Λογισμικό (Software)

Υλικό (Hardware)

Λογισμικό (Software)

Κεντρικό Σύστημα

(Υποδομή και Εφαρμογές)

½ Ώρα 3 Ώρες 6 Ώρες 6 Ώρες

Πίνακας 1

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

Όπου:

-Δ η διαθεσιμότητα,

-M οι ημέρες του μήνα (μεταβάλλεται ανάλογα με τον μήνα,

-Ω =24 ώρες της ημέρας και

-Α οι ώρες που το σύστημα είναι εκτός λειτουργίας

Για κάθε μήνα της προσφερόμενης περιόδου εγγύησης θα πρέπει να ισχύει Δ ≥ 99,9%.

Β. Διαδικασία αναγγελίας βλάβης - Αποκατάστασης προβλημάτων

1. Ο Ανάδοχος υποχρεούται να δημιουργήσει και να θέσει σε λειτουργία Κέντρο Τεχνικής Υποστήριξης του συστήματος. Το Κέντρο Τεχνικής Υποστήριξης θα ξεκινήσει τη


Έργο ΑΝΝΑ

λειτουργία του από την ημερομηνία έναρξης της περιόδου δοκιμαστικής λειτουργίας μέχρι το πέρας της περιόδου εγγύησης και θα λειτουργεί όλο το 24ώρο, επτά (7) ημέρες την εβδομάδα. Το Κέντρο Τεχνικής Υποστήριξης θα είναι κατάλληλα στελεχωμένο και εξοπλισμένο, ώστε να επιτυγχάνονται οι προβλεπόμενοι χρόνοι απόκρισης και αποκατάστασης προβλημάτων. Το Κέντρο θα διαθέτει τηλεφωνικό κέντρο καθώς και κατάλληλη υποδομή για λήψη και αποστολή FAX και μηνυμάτων ηλεκτρονικού ταχυδρομείου. Οι τηλεφωνητές του Κέντρου θα είναι κατάλληλα εκπαιδευμένοι, ώστε κάθε αναγγελία προβλήματος ή άλλου αιτήματος να προωθείται στον αρμόδιο ειδικευμένο προσωπικό του Αναδόχου.

2. Όταν το εξουσιοδοτημένο προσωπικό του ΛΣ-ΕΛΑΚΤ αντιλαμβάνεται ένα πρόβλημα θα ενημερώνει άμεσα το Κέντρο Τεχνικής Υποστήριξης. Στην αρχή της κλήσης ο χρήστης θα παρέχει τα στοιχεία του για την ταυτοποίησή του και τον αριθμό τηλεφώνου του. Εφόσον του ζητηθεί, οφείλει να δώσει μια σύντομη περιγραφή του προβλήματος. Με βάση τα αρχικά αυτά στοιχεία το Κέντρο Τεχνικής Υποστήριξης θα δημιουργεί μια νέα εγγραφή στη μηχανογραφική εφαρμογή παρακολούθησης προβλημάτων και θα γνωστοποιεί στο στέλεχος του ΛΣ-ΕΛΑΚΤ έναν αριθμό, ο οποίος θα προσδιορίζει μοναδικά το συμβάν (Ticket ID) ενώ στη συνέχεια το πρόβλημα θα παραπέμπεται στον αρμόδιο τεχνικό. Ο χρόνος για την αποκατάσταση της βλάβης-δυσλειτουργίας ξεκινά να μετρά από την καταχώρησή του συμβάντος στο Κέντρο Τεχνική Υποστήριξης.

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

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

5. Μετά την οριστική αποκατάσταση του προβλήματος, εκτυπώνεται σχετική αναφορά σε δύο (02) αντίτυπα, τα οποία υπογράφονται τόσο από τον αρμόδιο τεχνικό του αναδόχου όσο και από τον υπεύθυνο του ΛΣ-ΕΛΑΚΤ που διαπίστωσε την αποκατάσταση του


Έργο ΑΝΝΑ

προβλήματος. Από τα δύο αντίτυπα το ένα κρατείται στο Φορέα και το δεύτερο, με μέριμνα του τεχνικού του Αναδόχου παραδίδεται στο Κέντρο Τεχνικής Υποστήριξης, για αρχειοθέτηση.

6. Για την ορθή παρακολούθηση των υπηρεσιών τεχνικής υποστήριξης, το πρώτο δεκαήμερο κάθε μήνα, με μέριμνα του προσωπικού του Κέντρου Τεχνικής Υποστήριξης, θα αποστέλλεται στην αρμόδια Υπηρεσία του ΑΛΣ-ΕΛΑΚΤ, συγκεντρωτική κατάσταση με τις αναφορές των προβλημάτων που αποκαταστάθηκαν με ή χωρίς την παρουσία προσωπικού του Αναδόχου στις εγκαταστάσεις του ΑΛΣ-ΕΛΑΚΤ

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

11.9. Τήρηση Εγγυημένου Επιπέδου Υπηρεσιών – Διαθεσιμότητα - Ρήτρες

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

Χ.Μ.Α. =(Χ.Ε.Λ. - Μ.Χ.Α.Β.) * 36 * Κ.Μ.Ε.

, όπου Σ.Κ.Ε.

Χ.Ε.Λ. = Ο Χρόνος Εκτός Λειτουργίας της μονάδας εξοπλισμού σε ώρες.

Μ.Χ.Α.Β. = Ο Μέγιστος προβλεπόμενος Χρόνος Αποκατάστασης της βλάβης για τη συγκεκριμένη μονάδα εξοπλισμού σε ώρες.

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

Σ.Κ.Ε. = Το Συνολικό Κόστος του Εξοπλισμού (Hardware, Software, παθητικός εξοπλισμός κτλ), όπως θα καταγράφεται στην οικονομική προσφορά του υποψήφιου Αναδόχου.

Ο υπολογισμός του Χ.Μ.Α. θα πραγματοποιείται από τις αρμόδιες Υπηρεσίες του ΛΣ-ΕΛ.ΑΚΤ σε συνεργασία με τον Ανάδοχο, λαμβάνοντας υπόψη τη διαδικασία τεχνικής υποστήριξης που περιγράφεται παραπάνω.

Αμέσως μετά τη λήξη της περιόδου εγγύησης, θα υπολογιστεί από την αρμόδια Υπηρεσία Προμηθειών του Φορέα, η αναλογική έκπτωση ποσού από την εγγυητική επιστολή καλής λειτουργίας που θα έχει καταθέσει ο Ανάδοχος σε ποσοστό που θα υπολογίζεται από τον παρακάτω τύπο:

Ποσοστό Έκπτωσης (%) = 100 x (Συνολικός Χ.Μ.Α.) / (Συνολική Διάρκεια Περιόδου Εγγύησης σε ώρες).

Επισημαίνεται ιδιαίτερα ότι, για να καταστεί δυνατός ο ανωτέρω υπολογισμός απαιτείται να κατατεθεί, με την οικονομική προσφορά του υποψηφίου Αναδόχου,


Έργο ΑΝΝΑ

ανάλυση του κόστους ανά μονάδα προσφερόμενου εξοπλισμού και συνολικό κόστος εξοπλισμού, σύμφωνα με τους ανωτέρω ορισμούς.

Β. Διαθεσιμότητα Υπηρεσιών Συστήματος: Ο Ανάδοχος υποχρεούται για την τήρηση διαθεσιμότητας του συστήματος σε ποσοστό τουλάχιστον 99,9%, σύμφωνα με τα αναφερόμενα της Παρ. Στην περίπτωση που, βάσει των εργαλείων διαχείρισης ή/και των μηνιαίων αναφορών, διαπιστωθεί απόκλιση από τον ανωτέρω όριο, επιβάλλεται αθροιστικά ή διαζευκτικά ως προς την απομείωση της παρ. Α, κατά την κρίση της αρμόδιας Επιτροπής, αναλογική απομείωση ποσού από την εγγυητική επιστολή καλής λειτουργίας.

Στην περίπτωση που με τους ανωτέρω υπολογισμούς προκύπτει ποσό απομείωσης μεγαλύτερο του ποσού της εγγυητικής επιστολής, εφαρμοστέες τυγχάνουν οι διατάξεις του Άρθρου.34 του ΠΔ118/2007.

11.10. Οδηγίες Κατάρτισης Τεχνικών Προσφορών Υποψηφίων Αναδόχων

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

Α) Ρητή δέσμευση αποδοχής όλων των όρων του παρόντος τεύχους, οι οποίοι θα συμπεριληφθούν στην Σύμβαση.

Β) Όσον αφορά το Κεφ. 1 των τεχνικών προδιαγραφών, η τεχνική προσφορά αρκεί να περιλαμβάνει ρητά τη δέσμευση ότι ο υποψήφιος Ανάδοχος έλαβε γνώση των αναφερομένων, αποδέχεται τους εν λόγω όρους και δεσμεύεται να τους λάβει υπόψη κατά την υλοποίηση του έργου.

Γ) Όσον αφορά τα Κεφ. 2, 3 και 4 των τεχνικών προσφορών, η τεχνική προσφορά αρκεί να περιλαμβάνει ρητά τη δέσμευση ότι ο υποψήφιος Ανάδοχος έλαβε γνώση των αναφερομένων, αποδέχεται τους εν λόγω όρους, δεσμεύεται να τους λάβει υπόψη κατά την υλοποίηση του έργου και σε κάθε περίπτωση θα ενσωματωθούν στην πλήρη τεχνική πρόταση που θα κατατεθεί στη μελέτη εφαρμογής.

Δ) Όσον αφορά τα Κεφ. 5, 6, 7, 8, 9, 10 και 11 η τεχνική προσφορά θα περιλαμβάνει πλήρη περιγραφή της προτεινόμενης λύσης και υποβολή πίνακα συμμόρφωσης στο σύνολο των απαιτήσεων των εν λόγω κεφαλαίων, σημείο προς σημείο με την ίδια σειρά και αρίθμηση, με πλήρεις αιτιολογήσεις και παραπομπές σε τεχνικά εγχειρίδια, όπου αυτό είναι εφικτό, ώστε να τεκμηριώνεται πλήρως η αντιστοιχία των προσφερόμενων προϊόντων, υπηρεσιών, εφαρμογών και λογισμικού σε σχέση με αυτά που προδιαγράφονται. Επιπρόσθετα, δύναται να κατατεθεί οποιοδήποτε υλικό τεκμηρίωσης, όπως περιγραφικά φυλλάδια, φωτογραφίες και οτιδήποτε άλλο, που κατά την κρίση του υποψήφιου Ανάδοχου, μπορεί να υποστηρίξει την τεχνική προσφορά του.

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

ΣΤ) Μεθοδολογία εκπόνησης της μελέτης εφαρμογής


Έργο ΑΝΝΑ

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

Η) Ενδεικτικό Πρόγραμμα και Σενάρια Δοκιμών

Θ) Ενδεικτικό πρόγραμμα εκπαίδευσης

Ι) Μεθοδολογία παροχής υπηρεσιών εγγύησης, τεχνικής υποστήριξης και προληπτικής συντήρησης με πλήρη αποδοχή και συμμόρφωση στου όρους της Παρ. 11.8

ΙΑ) Αποδεικτικά της τεχνικής και επαγγελματικής κατάρτισης, σύμφωνα με την Παρ. 11.11

11.11. Τεχνική – Επαγγελματική Κατάρτιση

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

Κατάλογος των κυριότερων έργων που εκτέλεσε κατά τα πέντε (05) τελευταία έτη, ιδίως δε των αναλόγων με το αντικείμενο του υπό ανάθεση Έργου, με την εξής μορφή:

Α/Α ΠΕΛΑΤΗΣ ΣΥΝΤΟΜΗ ΠΕΡΙΓΡΑΦΗ ΤΟΥ ΕΡΓΟΥ

ΔΙΑΡΚΕΙΑ ΕΚΤΕΛΕΣΗΣ ΕΡΓΟΥ

ΠΡΟΫΠΟ-ΛΟΓΙΣΜΟΣ

ΠΑΡΟΥΣΑ ΦΑΣΗ

ΣΥΝΟΠΤΙΚΗ ΠΕΡΙΓΡΑΦΗ ΣΥΝΕΙΣΦΟ-ΡΑΣ ΣΤΟ ΕΡΓΟ

ΠΟΣΟΣΤΟ ΣΥΜΜΕΤΟ-ΧΗΣ ΣΤΟ ΕΡΓΟ

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

Εάν ο Πελάτης είναι δημόσιος φορέας ως στοιχείο τεκμηρίωσης υποβάλλεται πιστοποιητικό που συντάσσεται από την αρμόδια δημόσια αρχή ή το σχετικό πρωτόκολλο παραλαβής. Εάν ο Πελάτης είναι ιδιώτης, ως στοιχείο τεκμηρίωσης υποβάλλεται είτε βεβαίωση του αγοραστή είτε απλή δήλωση του υποψήφιου Αναδόχου.

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

Κάθε άλλο στοιχείο που τεκμηριώνει την εμπειρία του προσφέροντος στα ανωτέρω θέματα δύναται να κατατεθεί συμπληρωματικά ως προς τα ανωτέρω.

11.12. Δικαίωμα Προαίρεσης


Έργο ΑΝΝΑ

Ως δικαίωμα προαίρεσης ορίζεται η υλοποίηση του μέρους του Πιλοτικού Έργου 3 που σχετίζεται με τη διασύνδεση του υπό προμήθεια συστήματος με το αντίστοιχα πληροφοριακά συστήματα των τελωνειακών αρχών και της ΕΛ.ΑΣ, ήτοι το ICISNet και το SIS αντίστοιχα (βλ. Παρ. 7.2.4 – 7.3.4). Στην τεχνική προσφορά του υποψηφίου Αναδόχου θα πρέπει να περιγράφεται η μεθοδολογία υλοποίησης που θα ακολουθηθεί για την εν λόγω διασύνδεση καθώς και τα τυχόν προαπαιτούμενα στοιχεία τεκμηρίωσης. Οι Γενικοί Όροι του Κεφ. 11 για την εγγύηση, συντήρηση, τεχνική υποστήριξη, εκπαίδευση και διενέργεια δοκιμών θα δεσμεύουν τον Ανάδοχο στην περίπτωση που το εν λόγω δικαίωμα προαίρεσης ενεργοποιηθεί. Ως χρόνος παράδοσης του δικαιώματος προαίρεσης ορίζονται οι δύο (02) μήνες από την ενεργοποίησή του. Αντιστοίχως, ο υποψήφιος Ανάδοχος θα πρέπει να συμπεριλάβει στην οικονομική του προσφορά προσφερόμενη τιμή για το δικαίωμα προαίρεσης.

Ο προϋπολογισμός του εν λόγω δικαιώματος ανέρχεται στο ποσό των 90.000€ για τη διασύνδεση με το σύστημα των τελωνειακών αρχών (Παρ. 7.2.4) και στο ποσό των 50.000€ για τη διασύνδεση με το σύστημα της ΕΛ.ΑΣ (Παρ. 7.3.4) και χρηματοδοτείται από το υφιστάμενο πρόγραμμα συγχρηματοδότησης. Η άσκηση των δικαιωμάτων προαίρεσης από το ΑΛΣ-ΕΛΑΚΤ, εφόσον υπάρξει, τοποθετείται χρονικά πριν τη λήξη της προσφερόμενης περιόδου εγγύησης καλής λειτουργίας όπως θα περιλαμβάνεται στη Σύμβαση που θα συναφθεί.


Έργο ΑΝΝΑ

Λίστα Παραρτημάτων

I. ANNA MIG (Message Implementation Guide)II. ΑΝΝΑ Security Guidelines

III. eMS Data Mapping and Functionalities Sub-Group ReportIV. eMS National Single Window GuidelinesV. SSN XML Messaging Reference Guide v3.00

VI. SafeSeaNet Incident Report Guidelines v1.91


Documents

· Web viewΈντυπο FAL 7: Δηλωτικό επικινδύνων φορτίων Ναυτιλιακό δηλωτικό υγείας Πέραν των παραπάνω, ως