Specification Backoffice and GOS
Specification Backoffice and GOS
Specification Backoffice and GOS
Back Office
and
Pedestal Control System
CONFIDENTIAL
Camco Technologies
Technologielaan 13
B- 3001 Heverlee
Phone: 0032 (0) 16 389272
Fax: 0032 (0) 16 389274
Email : [email protected]
Camco’s Global Gate system concept is based on 3 separate applications. All those
applications are today commercial products can be used in stand alone mode or
combined. In the center we have the GOS. The GOS is the Pedestal Control system
communicating with the TOS.
For SAPO we configured 2 identical physical servers. One is the operational server,
the second one is a backup server. These servers will host all software applications:
• AGS (SuperGate OCR portals)
• GOS (Pedestal control system) and TOS Interface
• Minimum 4 GB Memory
• Minimum one, preferably a Dual XEON 3Ghz Processor
• 6 x 145GB RAID SAS Disks
2.2. Storage
As SAPO wants to keep pictures only for 6 months on line, storage can be done on
both application servers.
For storage 1,5MByte per passage should be calculated. For instance the system can
be configured up to 3Tbyte disks allowing up to 2,4 million pictures of trucks to be
saved. This is an average of 6.600 passages a day that can be saved for one year.
With the dropping prices of hard disks we propose to backup pictures to a second
identical configuration or to a platform that hosts the SuperGate Internet picture
retrieval software.
The only requirement is that the data should be stored in at least 2 different physical
locations (to prevent loose by theft or fire).
AGS
Cameras: Linux based, software is written in C and C++.
Windows: Software is written in C++, C# and.NET
LEC: Software is written in C
ACS
JBoss, J++,C#, .NET
GOS
C# and .NET
Pedestals
Uses Linux with software written in C
VMware is a virtual windows system, every application runs in its own virtual
windows environment in depended of the physical hardware.
Theoretically one physical server can hosts all Global Gate System applications. For
reason of redundancy we configure 2 to 3 identical hardware platforms. On every
physical platform we have VMWare installed. Every application runs in its own virtual
Windows on one of the systems. In case of problems, an application image can be
started on any of the physical servers.
Virtualization software as VMWare simplifies computing infrastructure by partitioning
and isolating servers in secure and transportable virtual machines each of which can
run standard Windows. To ensure high performance, each virtual machine has direct
access to the host machine’s resources such as CPU, memory, disk, networking, and
peripherals.
Pre-configured virtual machine servers can be built once quickly and deployed
anywhere immediately; provisioning a new server is as easy as copying a file, or just
PXE boot a new VM to download a system image.
VMWare makes our proposal more expensive but at the other hand creates a very
use friendly software maintenance solution and backup facilities.
GOS (Pedestal Control System) uses a database to keep track of the trucks passing
trough the terminal based on a “visitnumber”. Those access records are kept for one
year in the database. This is the most complex database.
AGS (SuperGate OCR Portal) uses one dedicated small database to store and
retrieve the picture zip-files. This database is embedded into the storage software.
Configuration of all applications are also stored in the central database (GOS).
Interfaces to the database providers are loaded dynamically using reflection, so that
multiple providers can be added without creating dependency problems.
Camco will use IBM DB2 Express Server for the SAPO project.
The LaneManager module handles the “outside” communication. For each OCR portal
lane a separate copy of this program runs. A LaneManager communicates on one
side via Ethernet with the hardware in the lane (Camera’s, traffic barrier, loops,
traffic lights..) and the other side across the LaneManagerInterface via an internal
TCP/IP interface with the GOS Service. Images (full, thumbnails, and cut-outs), data
(Tagreaders, Proximity readers) and OCR results are transferred from the Image
acquisition system (cameras) and LEC’s via the LaneManagerInterface to the GOS
and he Storage application.
This is a LaneManager of a Damage and OCR Portal lane. On the left the status of the
different cameras, on the right the results of the latest passage.
The LaneManager merges from every lane the received access data, timestamps,
OCR results and images into one ZIP- file. Such a file, called “passage-file”,
contains several sub-files. The first sub-file is an XML formatted file with all the
The LaneManegerInterface module will store a link to the picture file in the “visit”
record of the concerned truck.
This is the GUI of the LanMangerInterface. On the left of this monitor screen a list
with references. Every line is a passage with reference to a “visitnumber”, ticket
number, timestamps etc.
The ACS application also feeds via a Web Admin interface the Access control
database. It allows customers via a browser or computer systems (XML interface) to
dialog with the Access Control System.
Access administration
The ACS software is partly a J2EE based application; HTML JSP pages are
dynamically generated by using data from the database. The pages use a JDBC
connection towards the database to find the requested record.
The Storage Manager is a client/server application. The client sends the ZIP-files to
different physical Storage Servers. This software does the distribution and updating
of images and data between the different platforms.
The server part receives the picture files (ZIP-files). The files are stored in a
structured directory system. By use of the enclosed XML data files a local embedded
database is created. This allows retrieving the name and location of the image files
(ZIP files) by use of SQL queries.
This software is not an ordinary file-copy program but an intelligent file distribution
and updating system. A record changed in the source database is also updated in the
destination database.
The Storage Manager software also does automatically cleanup of the local
system. When the disk gets full, the oldest passage files will be deleted.
3.7.1. Introduction
• GOS is new developed software with state of the art tools, it’s a real C# .NET
application build up from scratch.
• Most part of the GOS is standard, customer specific parts are isolated into
what we call “Customer Business Process Software Components”
• Every GOS application is based on the same structure. It contains a GUI for
monitoring and logging. This GUI can be exported to a global monitoring and
logging system allowing easy maintenance.
GOS Components
• GOSVisitManager: Manage visits in database
• GOSEquipmentConnector Equipment communication modules
• GOSPrintManager Does printer management
• GOSJobManager Does the job management
• GOSSnapshotDataProvider Allow query of snapshots via the network
• GOSTosInterfacing TOS interaction component
• More…
GOS Interfaces:
Customer Business Customer Business Customer Business Customer Business Customer Business Customer Business
Customer Business
Process Software Process Software Process Software Process Software Process Software Process Software
GOS Software Process Software
CAMCO Technologies
Component Component Component Component Component Component
Component
Applications
Uses Uses Uses Uses Uses Uses
Uses
GOS Standard Software GOS Standard Software GOS Standard Software GOS Standard Software GOS Standard Software GOS Standard Software
GOS Standard Software
Components Components Components Components Components Components
Components
.NET Application .NET Application .NET Application .NET Application .NET Application .NET Application
.NET Application
Communication
Layer Uses
IP + TCP + GOS
communication layers
page 12
Hot Standby Main
Data and Image Database High Availability Data Database
Redundancy
Storage
Hot standby High Availability Data Main
Image file store Redundancy Image file store
Virtual Servers
(VMWare)
Virtual Server Virtual Server
Virtual Server Virtual Server
Virtual Server Virtual Server
Runs on Runs on
Runs on
Runs on Runs on
Physical Servers Runs on
Server Server
Server
15/5/2006
3.7.2. VisitManager
Main function
The VisitManager .NET assembly implements a service component to create, update
and control the visit data of trucks on a terminal.
Other components manipulate the data of a visit to execute a business process, such
a component is called a "visit processor". Those visit processors may not interact
directly with a database, but use data objects to execute their task.
The datamodel is not static but slightly different for each site. Therefore the
component uses the meta-data from the database at startup to build the internal
datamodel. The most important changes are on the level of columns of a table.
Tables are programmed fixed, together with keys and reference keys. However for
the data columns the meta information should be interpreted during service start.
VisitManagerViewer service
This service provides a GUI to allow monitoring the Visit processes
Some of the functions
Main function
This component provides a communication message link between the components
deployed on the server and the equipment installed in the field trough TCP/IP. It
concerns basicly the kiosks and other intelligent technology not related to the OCR
portal.
The GOS does not address physicly the kiosks hardware. A kiosk is seen as a named
“equipment” with additional named “devices” that can be controlled. The kiosk has a
“message controller” for communication between kiosk and the GOS and a “Device
controller” that steers the devices in the Kiosk.
GosEquipmentViewer service
This service provides a GUI to the GOSEquipmentconnector message handler
It delivers an overview of all equipment configurations
Per equipment
• status of the TCP connection
o timestamp connection created
o number of connections drops since service start
• number of messages received per minute (sliding time window 5 minutes,
updates each 30 seconds)
o from equipment to messagehandling
• number of messages send per minute (sliding time window 5 minutes,
updates each 30 seconds)
o from messagehandling to equipment
• for each equipment
o radiobutton to enable/disable freeze message updates on gui
o content of last 10 messages received
o content of last 10 messages send
This component is responsible to manage all printing devices and to execute a print
job on a print device. It also knows how to format certain document types based
upon visit information.
Main functions
• provide a uniform print mechanism for other components
• provide a customer dependent and a customer independent part
PrintManagerClient service
This optional service provides a simplified interface to launch print jobs over directly
exchanging print job messages with PrintManagerServer.
GOS Interaction
Its deployed as a service
Uses MessageHandling to receive print jobs
• Overview of successfully finished print jobs (content, truck plate?, start time,
end time, duration), will be marked as failed after a certain amount of time
(configurable)
o Possibility to view complete document content
• Overview of failed print jobs (content, start time, end time, duration)
o Possibility to view complete document content
• Overview of document types Possibility to add a free text remark (max. 255
chars) to each document
Main features
Concept
A Job represents a unit of tasks. Each Job is in a certain state. A component can add
application specific properties to a Job.
A JobQueue represents a sorted Collection of Jobs. When a Job is registered (added)
to a JobQueue, it state changes to Registered. A Job can only be added to a
JobQueue when its state is Created.
A component can implement a Listener interface to receive events on a state change
of a JobQueue.
The client component can use a rich image control to display the image on the
screen.
The server component contains a build-in http server to process http request of the
client component or other http client software.
• http tabpage
o contains for each http-server instance a separate tabpage
o contains Configuration groupbox
displays current configuration
enable/disable max download speed
enable/disable request limitation
o contains listview with last 50 request
columns: src ipadress, request param string, username, http
response code, turn-around time in msec (http request-
response), cache used?
o contains Statistics groupbox
download size/hour
download size/day
total nb request since service start
total download size since service start
Introduction
A Visit is the unit of data in the complete GOS. The interaction with a Visit during a
complete gate operation is:
• complex
• executed by different other GOS software components
• executed in a relative large timeframe (30-90 minutes)
The metrics showed are the standard ones, on customer requests other can
be implemented. Some metrics are counts, others are duration (expressed in
seconds). The statistics are from our system at APMT Rotterdam. It’s based
on 2 security kiosk ISPS kiosks, 2 SuperGates and 2 In-Gate kiosks.
• During that day (26/7/2006) 993 trucks passed trough the 2 ISPS kiosks
and 2 SuperGates (isp-start). It took average 16,32 seconds for
identification (isp-duration). This time is exclusive truck start/stop time.
• From those 993 trucks, 1/3 or 322 trucks drove trough the 2 automated
In-Gate lanes (igtp-start). Those 2 lanes were processed with only one
operator opposed to the other 4 lanes that had 4 operators.
• It took average 96 seconds for a trucker to enter all data at the in-gate
kiosk (igtp-driver-duration).
• About 96 transactions (igtp-auto-attempt) could be started in automatic
mode (without operator intervention as all data was available and
correct).
• From those 96 about 62 transactions were finished successfully (igtp-
auto-success), the remaining 34 truckers needed operator intervention
• About 47 truckers have been send to the help desk because of
uncompleted or wrong booking information (igtp-helpdesk)
• It took average 112 seconds before the checker did check the seal ( igtp-
inspector-delay-duration)
• It took average 91 seconds for the operator to finish a transaction (igtp-
operator-duration).
• A trucker had to wait average 60 seconds before the operator handled his
transaction (igtp-operator-delay-duration)
• The total time from ISPS security kiosk until the truck drives to the
interchange area takes average 277 seconds (A-check time)
The left panel gives all data available about this truck, including timestamps, speed,
name of driver, company etc…
3.9.1 Introduction
The kiosks (pedestals) runs or Linux or Windows.
The basic software makes part of our GOS Frame, only the screens are customized to
the customers requirements in different languages.
Driver has to select the type of action by touching one of the pictograms.