Notable Projects

Motorola Guardian ICCS

When you make a call to the emergency services you want that call to be answered as quickly as possible, by the best person with the best tools available to them.

That’s the aim of Motorola Guardian ICCS (Integrated Communication Control System). The natural progression of Cyfas MACS, Guardian ICCS is a SaaS hosted communications hub for the emergency services call centre. In telephony it handles emergency and non-emergency calls, supervision and take-over. On the radio side it handles talkgroups, monitoring, alarms, private transmissions and calls.

For the call-takers, operators and dispatchers it also interfaces with other systems, PNC, crime management systems, etc. to ensure that the user has the best possible information in front of them to make those critical, life changing decisions.

Tom was the technical lead for the project from 2016 to 2024.

Cyfas MACS was a bold, innovative project by a predominantly hardware focussed company to unify communications in the emergency services control room.

Unlike Motorola Guardian, MACS was targeted at the smaller control room with more diverse communications technology.

The key innovation behind MACS was that it was based on web technology and used standard PC hardware. Previous ICCS systems had required specialist hardware, complicated installation and maintenance.

MACS changed the model for emergency services for the UK.

Tom was the technical lead for the MACS project, through into its acquisition by Motorola Solutions.

In the control room, the counterpart to the ICCS is the Computer Aided Dispatch system, although the name now no longer describes the function. The CAD is now a full incident management system.

Before leading ICCS developments, Tom led the development of a CAD system for the Fire Service.

BRIGID Command and Control was a ground-up development, taking requirements directly from control room staff with the aim of building the most efficient possible system to support their workflows.

BRIGID Command and Control was in play the moment the 999 call was received, it queried BT’s EISEC system and initiated its own internal database lookup, presenting the caller information and any associated operational intelligence to the operator.

Having created the incident, a combination of the type of incident and its location was used to calculate an appropriate response. The (GPS) position of each applicable appliance was evaluated against a model of the road network and the position of the incident to find the most effective means of getting the right appliances to the incident as fast as possible.

At-a-glance views were always available via the “asset register” and map window that gave the states and positions of all the Service’s resources and all current incidents. Key pieces of operational intelligence associated with the location and the incident type were also available to assist the control room operator with deciding upon an initial response.

The operator was able to accept or quickly edit the system generated response proposal and mobilise the assets.

BRIGID Command and Control then entered the dispatch process, mobilising the appropriate appliances, officers and stations. It managed the dispatch so that any failures in the turnout process – be they communications failures or failures of assets to mobilise or arrive at the incident within acceptable times – were highlighted to the operator.

The operator was then able to manage the incident (and others) through to completion. The system received positional, status and operational updates from the in-vehicle terminals giving the operator a clear overview of the situation. Similarly updates from control were echoed to the devices in the field, keeping everyone dealing with the incident informed.

All the time the operator has access to operational intelligence associated with the incident and can manage the Service’s resources.

Tom Fosdick was brought into Seed Software specifically for the Command and Control project and was its architect from 2008 until 2015. Before Seed expanded in 2012, employing a full time business manager, Tom was also the Product Manager and was responsible for successfully managing development and delivery to the first customers.

An (early) brochure for the Command and Control System is available via the Science Web Site at Hull (pdf).

Co-Ordinator was a family of products that provided an AVL control desk and Mobile Information platform.

Through the desktop application users could see at a glance the live and historic positions and statuses of trackable assets. The application was interactive, allowing the user certain control over the GPS devices in the field.

The Programmer application could be used both locally and remotely with APD’s “Inca” Intelligent GPS radio-modem.

The Server system was the hub of Co-Ordinator. As well as serving multiple applications, the server could communicate with Inca and other GPS devices using a wide range of “bearer” technology, from analogue radio to GSM modems to TETRA to IP Networks (e.g. 3G).

As well as being a suite of applications in its own right, the Co-Ordinator Server system was also an enabling platform for mobile data applications. By providing a bearer independent data channel from a TCP endpoint on the server to an RS232 port on the in-vehicle Inca it was easy to develop reliable mobile data applications using the Co-Ordinator server.

Co-Ordinator reports was an application based on Crystal Reports that provided a simple MIS layer on top of the Co-Ordinator database.

Tom was initially brought in to the Co-Ordinator project in 2000 (because of his experience with both communications and databases) to develop the Co-Ordinator Reports product. Tom quickly moved onto developing the main product and, although involved in many other successful projects within APD, remained ostensibly in charge of Co-Ordinator through to 2008.

APD’s location solution is now known as ARTEMIS

Inca was the driver behind Co-Ordinator. It was an intelligent radio-modem that was quite revolutionary at the time. In the late 1990s communication was expensive. Inca was able to use relatively complex rules about what it should log internally, what information it should transmit immediately, what information it should transmit in log files and over which type of communications any of these should happen.

It could be used in a Police Pursuit Vehicle for instance such that it would log an update every 30 seconds and then send all the updates in a single GSM modem call once per hour. If the vehicle responded to an emergency however, this could be automatically changed to send a SMS giving the position of the vehicle every 1 minute or 1km (configurable) to the server (and the hourly updates).

Tom was a regular contributor to the project in the early 2000s.

A reasonable amount of information on APD’s Inca / Co-Ordinator offering around the time Tom was working on the project can be found in a PowerPoint presentation.

Oracle has an ODBC Driver, but it’s Windows specific. Easysoft’s Oracle ODBC driver was (relatively) platform independent, making it possible to use it on pretty much anything that Oracle produced connectivity libraries for (including Windows).

Database backed web sites were rapidly gathering pace around Y2K. People wanted reliable servers with familiar development technologies. Bringing ODBC to Unix was a clever strategic move for EasySoft and its range of Unix database connectivity products proved highly popular both with legacy data applications but also the rapidly expanding field of web applications.

Tom’s role at Easysoft was to develop Oracle products. Easysoft had only a sketch brief for each product, so Tom was the architect and product manager for each.

The OMC was, quite simply, a control system for multiple telephone exchanges. During the early / mid 1990s it was responsible for managing the vast majority of exchanges within the UK.

Tom was a programmer in the OMC team.

Tom worked on a number of research projects for BT at Martlesham, ranging from high speed DSP projects through to image processing. Although Tom was officially employed as an Electronic Technician at this time his role in these projects was generally as an embedded programmer.