Browse Prior Art Database

Voice annunciation using a publish/subscribe message broker

IP.com Disclosure Number: IPCOM000010104D
Original Publication Date: 2002-Oct-23
Included in the Prior Art Database: 2002-Oct-23
Document File: 3 page(s) / 45K

Publishing Venue

IBM

Abstract

In many industrial monitoring and control applications, a well-known technique for alerting operators of exceptional alert conditions, is "voice annunciation". This is generally inflexible: the annunciation unit has to be physically close to the application which is generating the alert, and changing the "text" of an announcement typically involves changes to the application. The proposed annunciation system is based on a publish/subscribe message broker infrastructure, such as IBM's WebSphere MQ Integrator, and network-connected annunciation devices, which can be located anywhere there is network access. Specialised processing nodes in the broker perform text-to-speech processing, producing a set of "phoneme codes" from an input text string. Announcements are "published" by the alert application on a certain topic, which indicates the category of users who should hear the alert. The broker matches the topic with the subscriptions of the voice annunciation units, which have been configured to listen out for certain categories of announcements, and sends a copy of the phoneme string to each validated subscriber unit. Decoupling the application from the text to speech conversion enables many administrative changes to be applied to the whole system from a central location, removing the need for costly reprogramming.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 3

Voice annunciation using a publish/subscribe message broker

In many industrial monitoring and control applications, a well-known technique for alerting operators of exceptional alert conditions, is "voice annunciation". This is the mechanism whereby a spoken, pre-recorded announcement is played through a loudspeaker near the operator's console. This ensures that the most urgent alerts come to the attention of the operator even if he or she is occupied with something else.

     The problem is that this is generally inflexible: the annunciation unit has to be physically close to the application which is generating the alert, and changing the "text" of an announcement typically involves changes to the application. Quite often, the alert messages are simply pre-recorded statements, which therefore do not include the possibility of adding "variable" components, such as the location of a problem, or a temperature reading, for example. So the announcement would draw the operator's attention back to the console, where they would see a visual indication of the nature of the problem. There are times when this increases the time taken to react to an urgent problem, compared with an announcement which could contain all the information.

     What we propose here, is a much more flexible voice annunciation system, decoupled from the monitoring application, which gives many more options for ensuring that the maximum effect can be derived from the annunciation "channel".

     The proposed annunciation system is based on a publish/subscribe message broker infrastructure, such as IBM's* WebSphere* MQ Integrator.

     The voice annunciation unit is intended to be a relatively low-cost device, comprising a loudspeaker, audio amplifier, a simplistic speech synthesis unit such as a phoneme synthesiser, and enough embedded computer infrastructure to support a TCP/IP stack, and an implementation of a subscriber client protocol, for example the MQ Integrator SCADA device protocol (MQIsdp). This might be implemented in a simple "PIC" processor, or a low-spec PC system, with a modest amount of memory and permanent (ROM) storage.

     The function of the annunciation unit, is to connect via a TCP/IP network to a pub/sub broker, and to subscribe to a topic which is specific to that unit, based on a unit name which is configured at installation time, and is stored in permanent (e.g. flash ROM) memory on the unit. e.g. "annunciators/desk_1". It is assumed that there will be several annunciator units in various locations both in the main operations centre, and in other locations such as rest areas, cafeteria, operations managers' offices, etc. The devices can be located anywhere there is network access, and with wireless LAN technologies this can be almost anywhere!

     The message broker has specialised processing "nodes", which examine messages being sent into the broker, and can produce new messages as a consequence of these messages. The specialised processing nodes for the voice annunc...