General Enterprise Architecture Principles :

• Use open standards, open data, open source and open innovation
• Apply simplicity in design : Can we achieve the same result with less integrations, less data, less components, more simple architecture
• Security by design : Security is a key priority within Port of Antwerp-Bruges and must be taken into account from the start in all design processes
• Data Protection by design & by default : In order to adhere to the (legal) requirements of data protection (cfr. Privacy/GDPR) & avoid non-conformities, warnings, incorrect incident mgt., fines, reputation damage etc. DPbD & DPbD is to be applied.

1. Software requirements

1.1 Applications

1.1.1 Extra os specific native apps to be avoided, responsive web ui recommended over all devices and screen form factors.

1.1.2 End-user Interface should be available in Dutch ( preferred ) or English language

1.1.3 At least 2 environments (TEST/PROD) should be available

1.1.4 Licensing and support models should be clear, transparent and predictable

1.2 Platforms ( managed by Port of Antwerp-Bruges ) :

1.2.1 The following deployment platforms are available

• VMware
• On premises cloud based LOKI (Linux-OpenStack-Kubernetes Infrastructure)
• Microsoft Azure is the preferred public cloud provider

Deployments should be Container based

1.3 SaaS-specific

1.3.1 Datacenters should be located within Europe

1.3.2 email services within the application on behalf of Port of Antwerp-Bruges should always use a subdomain ( e.g. @mail.portofantwerpbruges.com ) - SPF en DKIM and DMARC standards should be followed

1.3.3 If the SaaS-solution should use a *.portofantwerpbruges.com subdomain, necessary certificates should be provided ( e.g. https://letsencrypt.org ) and maintained by the SaaS-provider ( Port of Antwerp-Bruges will handle DNS-registration )

1.4 Custom development

1.4.1 source code of any custom development must be provided and stored in gitlab ( Port of Antwerp-Bruges ) and integrated with the existing CI/CD pipelines that result in docker based deployments on Kubernetes

1.4.2 Full DTAP environments are available, usage of at least 3 required

1.4.3 Documentation must contain schematic datamodel

1.5 Documentation

1.5.1 User manual is required

1.5.2 Installation manual is required

1.5.3 Administration manual is required

2. Security requirements :

2.1 Single sign-on authentication is mandatory for all applications with more than 5 end-users or if confidential or privacy related data is involved ( SAMLv2, Oauth or OpenID Connect are supported )

2.2 All traffic between clients and server should be sent over an encrypted connection ( SSL )

2.3 Passwords are hashed and salted before they are stored ( if no SSO is present )

2.4 Sensitive data at rest must be stored encrypted

2.5 No public internet based remote command and control tools are allowed (like LogMeIn, TeamViewer, …)

2.6 Generic user accounts must be avoided as much as possible

2.7 No site-to-site VPN tunnels will be allowed (eg. IPSec)

2.8. Vulnerability management

2.8.1. All systems and applications will be subject to Port of Antwerp-Bruges’s vulnerability scanner. This will happen by either installing an agent or via authenticated scan, whichever is more suitable.

2.8.2. The supplier is responsible for security maintenance of its systems and applications, unless it is agreed that this responsibility will be taken up by Port of Antwerp-Bruges staff. This means that the supplier commits itself to fixing weaponized exploits (= exploits that are being used in malware) within three business days after discovery; fixing vulnerabilities with a CVSS score equal to or greater than 7 two weeks after discovery, and vulnerabilities with a CVSS score below 7 three months after discovery. See also table below:

2.8.3. All internet facing systems and applications will be subject to Port of Antwerp-Bruges’s responsible disclosure and bug bounty program. The supplier commits itself to working together with Port of Antwerp-Bruges and the security researcher community to remediate security weaknesses in a timely manner.

2.9. The provision of accounts with administrative privileges must be approved by the CISO. Administrative privileges can be revoked at the discretion of the CISO when those privileges are no longer needed or a violation against the ICT Code of Conduct is detected.

2.10. Always use the principle of least privilige: an installed user application should run within the user ’s security context without the need for admin permissions.

3. Interface requirements :

3.1 Every application should have a restful API-interface available ( fully documented actions and errorcodes ) following guidelines at https://digitalspecs.portofantwerp.com/api-guidelines and all inbound en outbound integrations should be handled by API’s

3.2 In case of xml-based data exchange an xsd-file ( XML Schema Definition ) should be provided

4. Hardware installation requirements :

4.1 All server hardware must be 19” rackmountable and secured with M6 nuts & bolts. (No shelfs)

4.2 Server hardware should be equipped with dual power supply (feed A, feed B).

4.3 For optimal cooling, front to back airflow is recommended.

4.4 All network cables must be bundled with hook-and-loop fasteners (tie-wraps are not allowed)

5. Network requirements :

5.1 All network devices must be compliant with 100/1000Mbps autosensing full-duplex RJ45 ethernet ports

5.2 Network Access Control will be enforced. Device must be compliant with 802.1x authentication method (kerberos / username-password / certificate) or fallback to MAC-based to gain access.

5.3 Use of central DHCP and DNS services are preferred.

5.4 Out-of-band interface (power on / power off / console) is highly recommended

5.5 All devices are subject to periodic vulnerability scans. Exploitable vulnerabilities must be fixed immediately.

5.6 All wireless devices should be either WiFi or LoRa compliant. WiFi devices must be compliant with at least 802.11agn.

5.7 The introduction of a new wireless technology is only allowed if the requirements cannot be met by WiFi or LoRa. If a new technology is needed, it should be standards compliant and proven not to interfere with WiFi or LoRa. The implementation has to be open for (future) use by any product compliant to the same standard. Implemention is subject to approval of POAB.

6. Fysical requirements :

See fysical reqs

7. Machine Learning Solution Requirements :

7.1 Introduction

7.1.1 Conformance terminology

The key words below are used as defined in RFC 2119 and indicate the level of obligation attached to each requirement:

• MUST / MUST NOT — an absolute requirement or prohibition.
• SHOULD / SHOULD NOT — a strong recommendation; any deviation requires justification and prior approval.
• MAY / RECOMMENDED — optional, permitted, or advisable, but not mandatory.

7.2 Software and framework requirements

7.2.1 Programming language

7.2.1.1 Python MUST be the primary programming language for ML solutions.

7.2.1.2 High-throughput or I/O-intensive computer-vision operations MAY be implemented in Rust where performance requirements justify it.

7.2.2 Development environment

7.2.2.1 All development MUST take place on the Port of Antwerp-Bruges GitLab on a “develop” branch. Source code MUST be hosted in the corresponding Port of Antwerp-Bruges GitLab repository and MUST NOT be developed or stored in external or personal repositories.

7.2.2.2 Projects MUST be initialised from the standard project template (cookiecutter or substrate) maintained in the Port of Antwerp-Bruges GitLab.

7.2.3 Code quality and standards

7.2.3.1 Code MUST adhere to the PEP 8 style standard.

7.2.3.2 The following engineering practices are strongly RECOMMENDED:

• Type hints
• Automated code formatting
• Static code analysis
• Unit testing
• Dependency (vulnerability) scanning

7.2.3.3 Recommended tooling includes, but is not limited to: ruff (linting and formatting), mypy (static type checking), and pytest (unit testing). These practices and tools are pre-configured and enforced by the cookiecutter or substrate template.

7.2.4 Package management

7.2.4.1 Dependencies MUST be managed with uv.

7.2.5 Dependency management

7.2.5.1 All software dependencies MUST be specified with explicit, pinned versions. Acceptable mechanisms include:

• requirements.txt
• uv.lock
• A pinned Docker image

7.2.5.2 The delivering party MUST provide a complete overview of all third-party libraries, frameworks, and external services used by the solution.

7.2.6 Deep learning frameworks

7.2.6.1 Deep neural networks SHOULD be implemented using either TensorFlow or PyTorch.

7.2.7 Use of open-source and pre-trained models

7.2.7.1 Pre-trained or open-source models MAY be used only when their licence permits the intended use.

7.2.7.2 Only the model artifact itself (for example, .pt, .onnx, or .safetensors weights) MUST be used — not the surrounding wrapper or repository code.

7.2.7.3 In production, model weights MUST be served through an approved official serving runtime (see 7.4.3) or through reviewed, first-party inference code. The solution MUST NOT take a runtime dependency on unreviewed third-party repository code.

7.2.7.4 The licence of every pre-trained model MUST be documented and verified as compatible before use (see 7.2.10).

7.2.8 Containerization

7.2.8.1 Docker MUST be used as the containerization framework, and Docker Compose as the container orchestration framework for local and delivery environments.

7.2.8.2 Containers MUST run as a non-root user.

7.2.8.3 Where a standard Dockerfile template is provided by Port of Antwerp-Bruges, images SHOULD be based on it.

7.2.9 Cloud platform

7.2.9.1 Microsoft Azure is the preferred cloud platform and SHOULD be used for cloud solutions.

7.2.10 Open-source licenses

7.2.10.1 All open-source components MUST be documented, including their licence type.

7.2.10.2 Components with restrictive or incompatible licences MUST NOT be used without prior written approval from Port of Antwerp-Bruges.

7.3 Model requirements

7.3.1 Model purpose

7.3.1.1 The delivering party MUST clearly describe the purpose of the model, including:

• The expected input data
• The expected output
• Model biases due to lacking training data representation

7.3.2 Bias and fairness

7.3.2.1 The delivering party MUST take particular care to avoid model bias that results in discrimination against groups of people, and MUST document the measures taken to detect and mitigate such bias.

7.3.3 Privacy and data protection

7.3.3.1 The model MUST comply with applicable privacy law, including the GDPR.

7.3.3.2 The model MUST NOT infer sensitive information from non-sensitive data.

7.3.4 Interpretability and explainability

7.3.4.1 The delivering party MUST make the model as interpretable as is reasonably possible.

7.3.4.2 For high-impact or person-affecting use cases, the delivering party MUST provide explainability mechanisms where technically feasible.

7.3.5 Model performance

7.3.5.1 The delivering party MUST define and document the performance metrics used. The selected metrics MUST be appropriate for the model type and use case.

7.3.6 Validation set and continuous integration (MLOps)

7.3.6.1 Custom-trained models MUST be delivered with an untouched (held-out) validation set that captures all edge cases and functionalities the model is required to support. This set MUST be used to validate model behaviour as part of continuous integration (CI) and MUST NOT encode undesired biases.

7.4 Application architecture requirements

7.4.1 Service-based architecture

7.4.1.1 The application MUST consist of one or more services, each defined by a Docker image. Each service MUST have a clearly documented responsibility.

7.4.1.2 Services of the same architecture MUST communicate with each other using KAFKA or REST API calls. KAFKA is used when a service cannot exist without the producing service, otherwise REST API is used.

7.4.2 Inference service

7.4.2.1 Where possible, the model SHOULD be placed in a separate service (the “inference service”), which communicates with one or more separate services for pre-processing and post-processing. An inference service SHOULD produce KAFKA events or return REST API calls.

7.4.3 Model serving

7.4.3.1 Deep neural networks MUST be served using an official serving image appropriate to the framework:

• TensorRT — for NVIDIA-optimised models
• TorchServe — for PyTorch models
• TensorFlow Serving — for TensorFlow models
• ONNX Runtime — for ONNX-optimised models

7.4.4 API communication

7.4.4.1 Communication between services MUST occur through fully documented APIs or approved messaging mechanisms. RESTful APIs are preferred.

7.4.4.2 The application MUST be available through a fully documented RESTful API interface.

7.4.5 Lean services

7.4.5.1 Services MUST be as lean as possible. Docker images MUST NOT contain unnecessary packages, tools, source files, credentials, or temporary data.

7.4.6 Required build artifacts

7.4.6.1 All artifacts and input files required to recreate the Docker images MUST be delivered. Where applicable, this includes:

• Dockerfiles
• Dependency files
• Source code
• Configuration files
• Model artifacts
• Preprocessing artifacts

7.4.7 Resource requirements

7.4.7.1 The delivering party MUST document the required infrastructure resources, including:

• CPU
• Memory
• GPU, if applicable
• Network requirements
• Expected inference latency and throughput

7.4.7.2 For GPU-based solutions, the delivering party MUST additionally document:

• GPU type and CUDA version
• Driver requirements
• Required GPU memory

7.5 Model reproducibility requirements

7.5.1 Reproducibility

7.5.1.1 Model reproducibility MUST be ensured by providing all artifacts required to recreate the model, including:

• Model training pipeline
• Training data, or an approved data-access procedure
• Validation data
• Test data
• Hyperparameters
• Configuration files
• Random seeds
• Dependency versions
• Dockerfiles
• Model artifacts
• Evaluation scripts

7.5.2 Training pipeline

7.5.2.1 The model training pipeline MUST run in a Docker container to ensure reproducibility, and the delivering party MUST document how to execute it.

7.5.3 Training data

7.5.3.1 The delivering party MUST provide the training data used to train the model, unless legal, contractual, privacy, or confidentiality restrictions prevent this.

7.5.4 Dataset separation

7.5.4.1 Training, validation, and test datasets MUST be clearly separated.

7.5.4.2 Test data MUST NOT be used for training, feature selection, hyperparameter tuning, or model selection.

7.5.5 Experiment traceability

7.5.5.1 Each delivered model version MUST be traceable to:

• Source-code version
• Training-data version
• Configuration version
• Hyperparameters
• Evaluation results
• Date of training
• Responsible party

7.5.5.2 Use of an experiment-tracking system such as MLflow is RECOMMENDED.

7.5.6 Model versioning

7.5.6.1 Model artifacts MUST be versioned, and the application MUST expose or log the active model version.

7.6 Input and output requirements

7.6.1 Input/output overview

7.6.1.1 The delivering party MUST provide an overview specifying the expected file formats of the solution’s inputs and outputs.

7.6.2 Structured data model

7.6.2.1 For structured data, the delivering party MUST provide a data model describing the table schemas (column names and data types) and the relationships between tables.

7.6.3 Timestamps

7.6.3.1 Timestamps MUST be expressed as Unix timestamps in seconds or milliseconds.

7.6.4 Geographic coordinates

7.6.4.1 Geographic coordinates MUST be provided as longitude and latitude in decimal degrees.

7.7 Documentation requirements

7.7.1 A user manual MUST be provided.

7.7.2 A high-level schema of the application architecture SHOULD be provided.

7.7.3 A general description of the application MUST be provided.

Actual Port of Antwerp-Bruges standards :