EAL WinBAS ...
"A safety net, providing overview !"
The history of the WinBAS system is her future ...
We wrote 1988 at the time the first BAS (Dutch abbreviation for Fire department Alarm System) system was developed. At that time it was completely based on DOS of course, this however had no negative impact on success of the later developed WinBAS system. The continuous development of the system was not only based on the growing wishes of the customer, but largely on new technologies becoming available. This, along with the success of the system, was the foundation for EAL to base the development on Windows and rename the product in the year 2000 to WinBAS.
Next to the continuous growing request of the end-user for more and more functionality and the more sophisticated and user-friendly Windows platform, was the success of the system within the market enough reason for EAL to keep on developing the system even more.
Although upon today the product name of the system is still WinBAS, it hardly covers the capability of the system anymore. The ongoing developments provided a system that is basically incomparable with the BAS system, it all started with.
WinBAS is in fact a combination of applied electronics and modern software that enables to provide the end-user with a conveniently arranged overview on one or more screens, of the organizational and technological aspects of the operational management processes, adapted within the company.
Therefore it goes without saying that providing the end-user with an extensive technical conversion box, where nearly every system and development of an ever growing number and variety of telecommunication technology of different suppliers, was the main key to the success of the system.
Although it sounds strange, looking at the way WinBAS evaluated over the years towards the system it is today, it is more than likely for the development to continue this way into the future. Organizations will keep on changing as a result of technologic development or even instigate developments of the technology in order to meet the new demands of the organization and possible legislations. This has even been and will always be the main reason WinBAS will be developed even more to meet the demands of the end- user, keep providing a simple overview and interface to all systems concerned, towards the end-user.
This way of developing the system won’t change too much, although in the way the system is presented to the end-user the old lamp and button will face out rapidly.
A growing number of these old lamp and buttons are presented on a PC environment. This development provides the possibility to create icons that can change in colour, position, size and shape. The new opportunities created by the ongoing technological developments and demands on functionality and legislations, are not only the history of the WinBAS system, but will also be a large part of her future.
The complexity of the system allows new technologies, but ….
The complexity of the WinBAS system stretches the boundaries of what’s possible more and more and this is the main reason that from day one, a special team is handling everything that’s related to the WinBAS system.
This is important to keep the technologic overview of the system as a whole. Although the system can be used in a growing number of different environments, each with its own technology input and horizon and therefore different development strategies, it is of the utmost importance the principle of “one and the same system” will be kept in place. For this is the only way that EAL can guarantee to keep supporting the end- user, in every environment the system is used.
Due to the same complexity of the system there is a disadvantage as well. It is impossible to create a standard user manual for the system. It is impossible to write a manual that will explain all functionalities and combinations of functionalities and at the same time keep it user friendly. The result would be a far too thick and confusing manual, that wouldn’t inspire any end-user to read it.
That’s why EAL will emphasize that a manual is created at the request of the end-user and should therefore be considered to be a reference book, and should never be seen to be document explaining all functionalities into detail. Using the system will always be based on a combination of training, the reference book and experience.
The experience on the system will always stay important, because the system will grow continuously using and combining functionalities and new developments. WinBAS will always be a site specific configuration and therefore it can be totally different for any location, even within the same organization.
What is the real power of the WinBAS system
and what makes it so unique? ...
Like is stated before, the WinBAS system started as a modest Alarm Monitoring System. The system was developed to create an interface towards third party systems and translate the alarms to a “lamp and button panel”, but eventually grown out to be a multifunctional interface platform.
This multifunctional character of the system became even stronger when the system was enhanced to not only receiving an handling alarms from third party systems, but specialized to instigate and activate third party system and hosting critical processes within the organization.
But like expected that wasn’t the end of the wish for functionalities, just a few examples are:
- Staff files
- Available material
- Duty rosters
- Locations
- Contact information
- Incident classification
One of the important developments was enabling the system to collect all this information and present this in a interactive overview to the end user, providing the following information/ functionality;
- Building specialized team
- Creating specialized teams per specific incident, automatically
- Enabling the functionality for the staff, to report available/ unavailable using the telephone;
1. The system automatically guarantee the minimum number of people in the crew
2. The crew must exist out of predefined specialists
3. Staff-member and their function should automatically be linked
4. The system must be able to prioritize this combination within the crew and shift
- Availability overview of vehicles and other materials
- Prioritizing Incident
- Alarming staff-Members
- Alarming vehicles
There are situations where there are already administrative systems in place. These systems can hold for instance duty/ shift rosters, WinBAS can handle this situation as well. Although the staff members can report themselves available / unavailable, simply using the telephone towards WinBAS, and WinBAS will update her database, an extra functionality is the ability to pass this information on the other system within the organisation. The only requirement is a link between the system and if a specific link does not exist already, EAL will develop it.
Some communication tools WinBAS is using ...
WinBAS is already working with several communication protocols e.g.;
- ISDN 2 (Euro ISDN)
- SIP
- ISDN 30
- Analogue telephony *
- GSM
- SMS
- Mail
- Internet
- Radio communication Tetra (C2000 - Astrid)
- IVR
- XML (CSV - LDAP etc.)
- 5 TVO
- SDS
- POCSAG
It go’s without saying that each communication protocols requires rules to play by, but those can only be specified if all wishes and demands of an end-user is known.
Some examples of third party system,
WinBAS is already interfacing ...
- Entrance security systems/ Access control
- Administrative procedures (e.g. GMS, Abi Fire)
- Broadcast systems
- Communications environment
- I-Traffic (Mobile Messaging & Oriëntation)
- Voice recording, can be integrated within WinBAS system
- GIS application(s) (these can be a variety of roadmaps, but also contains building/ floor information or specific technical information regarding several systems.)
- Illuminated news trailer
- Building management systems
- Automatic/ sliding doors
- Video security systems (for instance camera control)
- Navigation systems in cooperation with EAL MoMo (VDO)
Hosting critical processes within the organization,
using the WinBAS system ...
As a result of the automatic handling of all this information within WinBAS, pure administrative information within the organization becomes an active part of critical company processes and transfers into necessary actions to organize and support incident handling. WinBAS does not only instigate and manage these interactive processes, but provides all related information on a screen in the Security/ Dispatch centre, or on several screen throughout the building.
These processes can be hosted within the WinBAS system, but can be kept within third party systems as well.
WinBAS can act and intervene if so wished for. This can be done by, for instance, using the following triggers;
- SMS
- 5 TVO
- IVR
- SDS, POCSAG
WinBAS in a multisite environment ...
There are several options to install and work with the WinBAS system. WinBAS can be used in a centralized/ decentralized situation, but can combine these situations as well. WinBAS can be installed in several locations, but programmed to handle all separate installations from one centralized installation during predefined hours.
This enables to install WinBAS in several offices that are not occupied during specified days or part of those days, to be handled from a sp0ecific location during those hours. At the moment the staffing in these unmanned offices are in again, they can take the full control over WinBAS back again, at the moment it is convenient. If the reason the staff comes back in the office is an alarm situation en the building is secured with an EAL Access Control System, WinBAS can be switched in central mode, at the moment the first staff member comes in, offering his pass to the entrance system.
At the same moment in time the WinBAS system can start a predefined automatic sequence opening sliding doors and presenting the latest information on an illuminated news trailer.
This will not only prevent losing valuable time, but the new arriving staff will be informed, without being in danger of having information on the base of “hear say”. These are of course just a few examples of what WinBAS can do for this type of organisation.
User-friendly system is a must and not just an option ...
For the reason the WinBAS system is being used more and more in critical situations within or on behalf of the organization, the user-friendly character of the system is always been a focus point within the EAL development.
The system in not developed for static gathering information, but to act upon this information in the way the end-user requires from the system. But in order to make it really user-friendly, it has to be presented is such a way to the end-user that within the look and feel of the presentation, he will recognise the own organisation.
Technical knowledge is not required,
understanding the system is a pro ...
The architecture of the system became more complicated by the day, but that did not affect the user – friendly character. Real technical knowledge of the system is not required for an operator, but is can’t harm to understand some of the building-blocks. Although this will be different for every system, we give some examples.
- Building-blocks within the EAL WinBAS system:
1. Area of responsibility
2. Incidents
3. Personal function
4. Function groups
5. Vehicles
6. Roster groups
7. Rotating rosters
8. Persons
9. City’s
10. Streets
11. Maps
- What is the purpose of each Block within WinBAS
- How and when do these blocks work together?
- How do we present this to the end-users?
- When is WinBAS responsible to supply and/ or handle a specific application and when is WinBAS only providing and acting as an interface to third party systems
Although all those question are not too difficult to answer individually, is it the number of different combinations, containing for instance the prioritising – and presentation towards the end-user. The variety of possibilities is so large, that a standard manual is impossible to make. Only at the time the system is specified for a specific customer, it will get an own identity and character.
What about the system documentation ...
The character of the WinBAS system is that there is no standard system. It is always a specific customer focused combination of the several building blocks. Although the principle of the system will always be maintained, every system will be completely different than any other system. The setup of the various building blocks - the way they interact or are dependant on each other will be incomparable with other systems.
The documentation will therefore always be specified to a specific installation. This also implies we only provide project documentation. This for the reason it is impossible to produce general system documentation, without ending up with a thick and confusing document with an overview of all possibilities of integration and interaction.
