SEAL Version 18.11.

1
System architecture & requirements guide
Contents
1 PRODUCT DESCRIPTION ___________________________________________________________________ 3
2 PRODUCT COMPONENTS __________________________________________________________________ 4
2.1 CORE COMPONENTS _______________________________________________________________________ 4
2.2 RELATED STAR STORAGE COMPONENTS __________________________________________________________ 4
2.3 COMPLEMENTARY 3RD PARTY PRODUCTS _________________________________________________________ 5
3 REFERENCE ARCHITECTURE ________________________________________________________________ 6
3.1 BASIC REFERENCE ARCHITECTURE FOR SEAL _______________________________________________________ 6
3.2 HIGH AVAILABILITY REFERENCE ARCHITECTURE FOR SEAL INSTALLATION ____________________________________ 8
3.3 CUSTOM REFERENCE ARCHITECTURE FOR SEAL INSTALLATION ___________________________________________ 9
3.4 CUSTOM ASSESSMENT _____________________________________________________________________ 10
4 SYSTEM REQUIREMENTS__________________________________________________________________ 11
4.1 HARDWARE REQUIREMENTS _________________________________________________________________ 11
4.1.1 SEAL core components ____________________________________________________________ 11
4.1.2 Related Star Storage components____________________________________________________ 12
4.1.3 Complementary 3rd party products __________________________________________________ 13
4.1.4 Content storage __________________________________________________________________ 13
4.1.5 Virtualization ____________________________________________________________________ 13
4.2 SOFTWARE REQUIREMENTS _________________________________________________________________ 13
4.2.1 Operating systems ________________________________________________________________ 14
4.2.2 Database systems ________________________________________________________________ 14
4.2.3 Recommended Internet browsers ____________________________________________________ 15
4.2.4 Java environment requirements _____________________________________________________ 15
4.3 OTHER REQUIREMENTS ____________________________________________________________________ 15
4.3.1 Microsoft SQL Server integration ____________________________________________________ 15
4.3.2 SMTP server integration ___________________________________________________________ 16
4.3.3 HCP platform integration __________________________________________________________ 16
4.3.4 Active Directory integration ________________________________________________________ 17
4.3.5 Microsoft .Net Framework _________________________________________________________ 17
5 DISASTER RECOVERY _____________________________________________________________________ 18
5.1 BACKUP AND RESTORE APACHE SOLR INDEX FILES __________________________________________________ 18
5.1.1 Activities on the Primary site ________________________________________________________ 18
5.1.2 Activities on the Disaster Recovery Site _______________________________________________ 18
5.2 SEAL DATABASE REPLICATION _______________________________________________________________ 19
5.3 CONTENT FILES REPLICATION ________________________________________________________________ 19
5.4 FINAL CONSIDERATIONS ____________________________________________________________________ 20
6 TECHNICAL ASSISTANCE __________________________________________________________________ 21

SEAL System architecture & requirements guide Page 2 of 22

1 Product description
SEAL (Secure Electronic Archive Library) is an integrated enterprise information archiving
system, addressing both the needs derived from business processes and from high compliance
standards.
The current document applies to SEAL 18.04.1 version. For older versions please check the
previous version if the System Architecture & Requirements Guide.

SEAL System architecture & requirements guide Page 3 of 22

2 Product components
2.1 Core components

J2EE application, packaged as a J2EE enterprise archive (EAR), including:

- SealAdminWeb.war, a web module used by administrators to browse,
search, manage and generate reports of the electronic archive.
SEAL Admin
- SealCMISServer.war, a web module standing as a CMIS 1.1 server
Application
implementation
- SealClientWeb.war, a web module used by clients to browse and search
the electronic archive.

J2EE application, packaged as a J2EE enterprise archive (EAR), including

several modules for:
SEAL
- REST API interface (SeaIngestionWeb.war)
Asynchronous
- Asynchronous long-term processes execution
Application
- SAP ArchiveLink HTTP content server implementation
(SealSapHttpContentServer.war)

Enterprise index platform used for content and metadata index and fast
search operations. It is delivered as a standalone application (including
Apache SOLR Jetty container libraries).
7.3
Note: At least 3 Apache ZooKeeper services must also be installed when a
HA architecture is required, to create a SolrCloud environment.

JavaScript library used by SEAL graphical user interface, packaged as a J2EE

Dojo
web application archive (WAR).

JavaScript library used by SEAL browser embedded files viewer, packaged

seeIt
as a J2EE web application archive (WAR).

2.2 Related Star Storage components

Additional Star Storage product, whose purpose is to process files in order

SeeIt Server to produce images delivered in SEAL browser embedded viewer. It is
supported only for Windows platform (Windows Service).

SEAL System architecture & requirements guide Page 4 of 22

 Note: We recommend that the server where SeeIt Server will be installed
also have a GPU with minimum 512MB memory.

Windows desktop application that enables user driven file upload to

SEAL Uploader archive. The application is delivered within SEAL package and is available
for download directly from SEAL interface.

Windows service application that enables automated batch upload to

SEAL Uploader archive.
Service
It is an optional component, available on demand.

Windows desktop application that enables scanning, indexing and sending

documents to the archive.
Star Capture 5
A limited features edition is available for use and included in SEAL license.
Desktop
The application is delivered within SEAL package and is available for
download directly from SEAL interface.

Windows desktop application, integrated within the SEAL web

SEALSigner administration application, used by the archive administrators to apply
digital signature on recently uploaded documents.

SEAL Send emails and attachments to SEAL archive. Compatibility with

Microsoft Microsoft Outlook 2013.
Outlook Plugin It is an optional component, available on demand.

Microsoft Windows desktop application that imports PST files into an

SEAL PST electronic archive.
Ingestor
It is an optional component, available on demand.

2.3 Complementary 3rd party products

The following products are not part of SEAL product, but are necessary for SEAL deployment.

Application The current supported server for SEAL core apps is WildFly 13.0.0.Final.
server

SEAL System architecture & requirements guide Page 5 of 22

 Recommended HTTP web servers:
- Apache Web Server version 2.4
Web server
- Nginx Web Server

Content store platform may be one of the following:

- The Hitachi Content Platform (HCP) v6 or later

- File system
Content
Platform - Any storage managed by Tivoli Storage Manager V6.2 Fix Pack 3
Server (TSM 6.2.3)

- An EMC Documentum Content Server V6.7 (deprecated).

SEAL database server. May be one of the following:

- Microsoft SQL Server
Database - Oracle Database Server
Server - PostgreSQL Database Server

Please check chapter 4.2.2 for compatible versions.

3 Reference architecture
The deployment architecture for the SEAL platform, embedded and 3rd party components will
be established for each environments distinctly, based on the environment purpose (TEST or
PRODUCTION) and on the number of concurrent users that access the system and archive
ingestion rate (number and size of documents per unit time).
In the next sub-chapters some examples of system architectures are presented, including only
SEAL core components.

3.1 Basic reference architecture for SEAL

SEAL System architecture & requirements guide Page 6 of 22

 Figure 1

In a basic architecture, recommended for a reduced ingestion rate and concurrent users, all SEAL
core applications can be deployed on a single application server (one JVM instance), while the
Apache SOLR application can be deployed on distinct application server (second JVM instance)
installed on a different server, as described in the above image, or even on the same server.
The storage can be Hitachi Content Platform or other supported storage: file system, IBM Tivoli
Storage Manager or an EMC Documentum content server.

SEAL System architecture & requirements guide Page 7 of 22

3.2 High availability reference architecture for SEAL installation

Figure 2

When the ingestion rate requirements increase and/or the number of concurrent users that will
be accessing the system, a scaled architecture is recommended, as described in the above
image.
This type of architecture will also fulfill high availability requirements.
SEAL core applications are installed in two application server clusters, while SOLR is deployed in
a SOLR Cloud distributed architecture, with two replica nodes. The SOLR Cloud will require
minimum three ZooKeeper services, which can be installed on three servers from the
architecture.
In order to scale independently, depending on the evolution of the application SEAL activities
are divided into:
- Synchronous activities - processes that involve web interface and must have a
reasonable response time to ensure user comfort.

- Asynchronous activities - processes involving large volumes of data and are designed to
be performed asynchronously (for example: data exports).

These activities are grouped in different J2EE applications to be installed on different servers, as
follows:

SEAL System architecture & requirements guide Page 8 of 22

 - SEAL Client Application and SEAL Administration Application implement synchronous
activities. In the above image, these are deployed on the SYNC APP SERVER CLUSTER.

- SEAL Asynchronous Application implements asynchronous activities (including

ingestion and integration services). In the above image, these are deployed on the
SYNC APP SERVER CLUSTER.

Based on the specific implementation requirements, when using the above reference
architecture, the ingestion, index & search and client applications can be scaled independently,
by increasing or decreasing the number of servers or the number of JVM installed in each cluster.
The storage can be Hitachi Content Platform or other supported storage: file system, IBM Tivoli
Storage Manager or an EMC Documentum content server.

3.3 Simplified HA architecture for SEAL installation

The following image is an example of a customized SEAL architecture, for an implementation
that has a relative reduced number of concurrent users and a reduced ingestion rate, but
requires intensive index and search operations.
For these requirements, all three core SEAL applications where collocated on a single application
server cluster, while the Apache SOLR application was deployed on distinct dedicated servers.

Figure 3

SEAL System architecture & requirements guide Page 9 of 22

3.4 Custom assessment
For custom business requirements, a Star Storage technical consultant can assist in designing a
suitable architecture. For this process, the customer should be able to provide answers for the
following questions:

1. How many documents will be stored in the electronic repository?

2. What is the average file size of the documents?
3. Do you need full text index?
4. Do you need paper conversion provided by StarCapture product?
5. How many documents do you expect to be saved on a daily basis?
6. Do you expect to have bulk uploads in the repository? If yes, please provide some
estimated numbers related to batch size and frequency of bulk uploads.
7. How many users will access and search the document repository?
8. How frequent will the users access the repository (concurrent users)?
9. Do you request a 3rd party system integration with SEAL?
10. What type of operations do you expect, if an integration is required:
a. Uploads from 3rd party system(s)?
b. Search operations from 3rd party system(s)?
c. Content download from 3rd party system(s)?
d. Other (please specify)?
11. How many concurrent calls do you expect in the integration scenario?

For additional details, please contact Star Storage using contact details included in chapter 5.

SEAL System architecture & requirements guide Page 10 of 22

4 System requirements
4.1 Hardware requirements
4.1.1 SEAL core components
SEAL core components will be deployed on WildFly 13.0.0 Final, on a single or more instances
(JVMs), based on the environment architecture (please see the previous chapter).
The Apache Solr is a standalone application (it embeds Jetty container)).
The hardware requirements are variable and depend significantly on:
- The number of concurrent users that will be accessing the applications (please take
into consideration system concurrent calls, when integrating SEAL with other
applications).
- The ingestion rate of documents (number and size of archived documents per unit
time)
- The number and complexity of search operations.
The memory parameters for the JVMs should be configured as appropriate for each use-case.
The metrics and estimates below are only a suggestion and on different systems may vary.
Suggested hardware requirements for each server with a J2EE application installed:
Server Per JVM
CPU Disk space
memory memory
Up to 50 concurrent users 16 GB 2 GB 4 vCPU (or 80 GB
Up to 1.000 objects/day 1x3.2 GHz (OS requirements not
Quad core) included)
Up to 100 concurrent 16 GB 4 GB 4 vCPU (or 80 GB
users 1x3.2 GHz (OS requirements not
Up to 10.000 objects/day Quad core) included)
Up to 200 concurrent 32 GB 4 GB 8 vCPU (or 2 x 80 GB
users (consider 2 JVMs) 3.2 GHz Quad (OS requirements not
Up to 30.000 objects/day core) included)

Note 1: Consult a Star Storage technical consultant for requirements and best practices in
environments with more than 200 concurrent users or larger ingestion rates.
Note 2: Disk space does not include the space necessary for the data files. This space will be
estimated based on the volume of documents.
Note 3: Even for small environments, a 64-bit operating system is recommended.

SEAL System architecture & requirements guide Page 11 of 22

4.1.2 Related Star Storage components
The following represent the minimum hardware requirements for Star Storage components
integrated with SEAL product.
Please note that the RAM memory requirements should always be correlated with installed
operating system requirements and all the additional software installed should be taken into
consideration as well.

Workstation/
Component Server CPU Disk space
memory
100 MB or more
SeeIt Server 2 vCPU (or 1x2.0 GHz
4 GB 1 GB recommended (for
Dual core)
cache files)

SeeIt Client N/A (It will be deployed along with SEAL core applications)

50 MB
SEAL Uploader 2 GB 2GHz single core (Electronic files storage
not included)
50 MB
SEAL Uploader Service 2 vCPU (or 1x2.0 GHz
4 GB (Electronic files storage
Dual core)
not included)
500 MB
Star Capture 5 Desktop 2 GB 2GHz single core (Electronic files storage
not included)
StarSignUI
2GHz single core /2 100 MB
StarSign Service 2 GB/4GB vCPU (or 1x2.0 GHz (Electronic files storage
SEALSigner Dual core) not included)

SEAL Microsoft Outlook

Plugin 2 GB 2GHz single core 100 MB

100 MB
SEAL PST Ingestor 2 GB 2GHz single core (Electronic files storage
not included)

SEAL System architecture & requirements guide Page 12 of 22

4.1.3 Complementary 3rd party products
The following hardware requirements represent only some suggestions and when setting up a
new environment the specific vendor requirements and system load estimation should be
taken into consideration.

Server memory CPU

Web Server (Apache Web, Nginx or similar 2 vCPU (or 1x2.0 GHz Dual
4 GB
HTTP server, per node) core)

4 vCPU (or 3.2 GHz Quad

Database Server (per node) 16 GB
Core)

4.1.4 Content storage

SEAL stores each electronic file as is and for each one it also stores an XML file containing
electronic document metadata, so when computing storage requirements you should take into
consideration an average of 2.5 KB overhead for each file.
All export results (CSV metadata files) will also be stored on the underling storage, so add a
sufficient buffer for those documents also.
When using HCP storage, please keep in mind that HCP has a setting named DPL (data protection
level). This setting determines the number of copies of the object data and custom metadata
HCP must maintain. Typically, the DPL setting for an HCP system is the optimal setting for the
type of physical storage the system uses. For RAIN systems, this is 2. With SAIN and VM systems,
the SAN arrays provide a high level of data protection, so the optimal DPL setting is 1.
Therefore, when estimating the necessary storage, take into consideration the DPL value
(multiply the effective content size with the DPL value). For more details please check the HCP
documentation also.

4.1.5 Virtualization
SEAL core components can be installed on either a physical or a virtualized server, for instance
using Hyper-V or VMWare ESXi.

4.2 Software requirements

The application can operate with the following software environment.
Other combination of software elements is not officially supported (even if the application can
be put into operation without apparent problems).

SEAL System architecture & requirements guide Page 13 of 22

4.2.1 Operating systems
SEAL core components can be deployed theoretically on any operating system where Java SDK
version 10 is available, as all the core components are built on J2EE platform independent
technology.
Supported operating systems for SEAL core components (tested configurations):

Microsoft Windows Server 2016

Microsoft Windows Server 2012 R2

Microsoft Windows Server 2008 R2

Cent OS 7

Cent OS 6

Other compatible operating systems for SEAL core components:

Red Hat Enterprise Linux 7 (latest update)

Red Hat Enterprise Linux 6 (latest update)

Supported operating systems for Star Capture 5 Desktop:

Microsoft Windows 7

Microsoft Windows 8.1

Microsoft Windows Server 2008 R2

All other SEAL client applications and related Star Storage products (SEALUploader,
SEALUploader Windows Service, StarSign Service, StarSignUI, and SeeIt Server) are compatible
with Microsoft Windows operating systems, at minimum MS Windows XP SP3.

4.2.2 Database systems

SEAL core applications support the following database servers:

SEAL System architecture & requirements guide Page 14 of 22

 Microsoft SQL Server 2016 (recommended)

Microsoft SQL Server 2014 (recommended)

Microsoft SQL Server 2012

Microsoft SQL Server 2008 R2

Oracle Database 12c

Oracle Database 11g

PostgreSQL 10

PostgreSQL 9.3 – 9.6

4.2.3 Recommended Internet browsers

When accessing SEAL web applications please consider using one of the following recommended
web browsers:

Internet Explorer 9 – 11, Edge

Mozilla Firefox 25 and later

Google Chrome 32 and later

4.2.4 Java environment requirements

On SEAL core components servers Oracle Java SDK 10 latest available update is required.
Client computers do not need any Java runtime to access SEAL applications.

4.3 Other requirements

4.3.1 Microsoft SQL Server integration
The following prerequisites are necessary with a Microsoft SQL Server environment.
SEAL will require:

SEAL System architecture & requirements guide Page 15 of 22

 - MS SQL Server instance server address (and port, if not the default one: 1433)
- MS SQL Server instance name (if present, or blank if the instance is default)
- MS SQL Server login name and password. The login name must have at least dbcreator
server role (although sysadmin is recommended, in order to activate the XA transactions).
Please read the following steps for additional details about creating the login.

During SEAL installation and setup, at least 2 databases will be created (one for the main product
configuration, and then a new database for each electronic archive). For this reason, SEAL uses
XA transactions (please check the installation guide for further details on how to activate XA
transactions).
Be sure to:
1. Have connectivity between SEAL server(s) and MS SQL Server (on port designated port, usually
1433)
2. Enable TCP/IP Network protocol for MS SQL Server

4.3.2 SMTP server integration

SEAL uses SMTP server to send email notifications. SEAL setup will require:
1. SMTP server address (and port, if not the default one: 25)
2. SMTP server username and password (if authentication is required)

Be sure to:
1. Have connectivity between SEAL server(s) and SMTP server (on port 25)
2. Configure SMTP server to allow emails to be sent from SEAL server(s)

4.3.3 HCP platform integration

SEAL can use HCP platform to store content files. SEAL setup will require:
1. HCP domain name (e.g.: hcp50.demo.local)
2. HCP host name (the host name registered in DNS server or in hosts file. E.g.:
admin.hcp50.demo.local).
3. HCP user account (username and password). This account must have all roles necessary to
create tenants, namespaces and to perform security operations (create new user accounts and
assign security). The roles are: Administrator, Security, Monitor, Service, Compliance and
Search.

Be sure to:
1. Have connectivity between SEAL servers and HCP platform, on HTTP & HTTPS default ports
(80 and 443).
2. For management and troubleshooting purpose be sure you also have connectivity on console
port (the default is 8000)

SEAL System architecture & requirements guide Page 16 of 22

 3. Enable Management API on the HCP platform (from Security-> MAPI menu on the HCP platform
system management console). It is mandatory event if the tenant and namespace are created
manually.
4. For MAPI enable access on 9090 port from SEAL servers to each HCP node.
5. If HCP tenant and namespace is created from HCP console, then make sure to enable HTTP
protocol (it is disabled by default).

4.3.4 Active Directory integration

SEAL can integrate with Microsoft Active Directory for user synchronization and authentication.
Configuring Active Directory connection in SEAL requires the following information:
1. Active Directory server address and port (and port, if not the default one: 389)
2. An Active Directory user, dedicated to the SEAL installation that will be used to query Active
Directory structure (domain\username and password)
3. Base DN for users search: the base DN from directory, where application will search user
accounts (e.g.: ou=organizationname,dc=company,dc=domain)
4. Base DN for groups search: the base DN from directory, where application will search security
groups (e.g.: ou=organizationname,dc=company,dc=domain)
5. Active Directory security group name. A security group dedicated to SEAL installation must
be provided (for best practices is preferred to have distinct user groups, for TEST and
PRODUCTION environment)

Be sure to:
1. Have connectivity between SEAL server(s) and Active Directory server (on 389 port)
2. Create the security group and place all the users that will use the SEAL application within it.
3. All SEAL users have a configured email address (otherwise their accounts cannot be used with
SEAL application).

4.3.5 Microsoft .Net Framework

The following SEAL related components require .Net Framework (3.0 or newer):

SeeIt Server

SEAL Uploader Windows Service

SEAL System architecture & requirements guide Page 17 of 22

5 Disaster Recovery
A Disaster Recovery Plan (DRP) for SEAL will cover three SEAL data layers:
1. Backup & restore of Apache Solr index files
2. Replication of software data, including documents metadata values stored in the SEAL database.
3. Replication of content files (stored on Hitachi Content Platform).

The order of operations in the disaster recovery plan schedule is very important and should be
the one mentioned above in order to avoid data inconsistencies:
- Database timestamp must always be older then the content timestamp (to avoid records
without content in case of a swith to the DR site);
- Database timestamp must be always newer than the index timestamp (in order to avoid
displaying in search results of records that are not found in the database).

5.1 Backup and restore Apache Solr index files

This plan is required in order to synchronize Solr index files from primary site to disaster recovery
site. In each site, a full Apache Solr environment must be installed.

5.1.1 Activities on the Primary site

For each Apache Solr collection (we assume SEAL environment to have an Apache Solr Cloud
architecture, to ensure high-availability) a scheduled script will backup index files and copy
backup folder to the Secondary Site.
A curl command can be used to backup index files, like in the following example:
curl 'http://localhost:8983/Solr/collection_name/replication?command=backup&name=backup01’

5.1.2 Activities on the Disaster Recovery Site

A curl command can be used to restore index files, from the copied folder, like in the following
example:
curl 'http://localhost:8983/Solr/collection_name/replication?command=restore&name=backup01'

The restore script must be scheduled in the disaster recovery plan in such a way that index files
are always older then the database version. Missing index values will be recomputed by SEAL
instance, when the DR site becomes the active site, by running the Rebuild SOLR index process.

Note: Starting with Apache Solr 7.1, as an alternative to the backup and restore procedure
described above, Cross Data Center Replication can be configured, as described in Apache Solr

SEAL System architecture & requirements guide Page 18 of 22

reference guide: https://lucene.apache.org/solr/guide/7_1/cross-data-center-replication-
cdcr.html.

5.2 SEAL database replication

SEAL database replication will be assured using specific database mechanism. The mechanism
used for metadata replication depends on RDBMS system in place.
For example:
1. Microsoft SQL Server: Database mirroring (Standard Edition) or Always On availability
groups (Enterprise Edition)
2. Oracle Database Server: Oracle Real Application Clusters + Oracle Streams (Standard
Edition) or Oracle Real Application Clusters + Oracle Active Data Guard (Enterprise
Edition)

5.3 Content files replication

When SEAL content files are stored in the HCP platform then the DRP will include a HCP system
to another HCP system replication procedure. The following details cover only this scenario.
If content is stored on regular file server partition, then replication can be performed using other
infrastructure software technologies.

Replication, a HCP service, is the process of keeping selected tenants and namespaces in two
HCP systems in sync with each other. This entails copying object creations, object deletions,
metadata changes, and other information between the two systems. Typically, the two systems
are in separate geographic locations and are connected by a high-speed wide area network.

Replication occurs between two separate HCP systems, each of which is complete in its own
right. Because replication is a software function, the two systems can have entirely different
hardware configurations, including differing amounts of storage. The two systems in a replicated
pair are connected through the front-end network infrastructure, as shown in the figure below.
Replication traffic from each system must be routable to the network selected for replication on
the other system.

SEAL System architecture & requirements guide Page 19 of 22

Replication is a network bandwidth-intensive process. To ensure sufficient front-end network
capacity when replicating, is needed to give extra consideration to planning the front-end
infrastructure.
HCP Replication can occur:
1. In two directions on a single link between two HCP systems (active/active replication)
2. In one direction on a single link between two HCP systems (active/passive replication)
3. From multiple HCP systems to a single HCP system (many-to-one replication)
4. From one HCP system to a second HCP system and from that second system to a third
HCP system, such that the same HCP tenants and namespaces and default-namespace
directories that are replicated to the second system are then replicated to the third
system (chained replication)
5. From one HCP system to multiple other HCP systems (one-to-many replication)

These configurations can be combined to form complex replication topologies.

For HCP systems dedicated only to SEAL environments the appropriate HCP replication topology
can be the second mentioned above. The strategy for each customer should be decided only
after analyzing business requirements and system setup architecture.

5.4 Final considerations

The activities described above represent only technical guidelines to be followed when
designing a Disaster Recovery Plan for SEAL, in order to support business continuity.
A real customer dedicated Disaster Recovery Plan can be provided based on the assessment of
customer hardware and software infrastructure.

SEAL System architecture & requirements guide Page 20 of 22

6 Technical Assistance
Contact Star Storage for any questions, suggestions or details.
Technical support contact:
Phone/Fax: +40372227910, +40374107410
Email: service.desk@star-storage.ro
Web: https://support.star-storage.ro
We are always looking at ways to improve SEAL platform and you can help by providing us
feedback about the product. Feedback can consist of any changes you would like to see, as well
as the problems you have encountered. Please send us your feedback by sending an email
message to the following address:
products@star-storage.ro

SEAL System architecture & requirements guide Page 21 of 22

SEAL System architecture & requirements guide Page 22 of 22