As highlighted in chapter 4, field engineers require audio communication facilities in order to be able to interact with the control centre and coordinate activities with their colleagues. In addition, audio communication support within the application prototype is essential for two further reasons :-
Conference management
In applications which provide data only interfaces between cooperating parties, the system is responsible for providing “floor-control” protocols for governing how a user’s operations affect the state of the group. For instance, one user might be designated the “speaker”, their operations will take precedence until they yield the floor by nominating another user. The tasks undertaken by field engineers are highly diverse, varying in response to the demands of a given scenario. The application is based on the premise that providing a data-only interface to engineers faced with a wide range of non-deterministic tasks would be too constraining. Instead, by providing audio communication facilities a social protocol between the engineers can determine the most appropriate form of dialogue and coordinate group interactions.
Safety criticality
Field engineers, by their very nature, are required to work with voltage distribution networks which pose a threat to their safety. Currently, it is only through physical security mechanisms (such as those described in section 4.2.3) and verbal dialogues with the control centre, that potentially hazardous inconsistencies in network state are discovered. Audio dialogues contain a wealth of implicit safety and state information and are essential for providing context to collaborative data operations. Furthermore, experience within the utilities industries regards audio communication as inherently safer (and of course, more familiar) than data communication.
The remainder of this section describes the supporting components of the audio communications module in more detail.
5.3.3.2 Base Services
The audio conferencing module is responsible for establishing group audio communication between selected conference participants. The module relies on a set of multimedia transport services to provide the underlying management and transmission of the audio information. These services, known as the Base Services are based on earlier work at Lancaster University on developing a set of RM-ODP compatible services for managing the transmission of continuous multimedia data [Coulson,92] . Source Source Source Sink Sink Sink Source Group Sink Group Stream
Figure 5.9 - Conceptual overview of the Base Services
Conceptually, the Base Services consist of three components: devices, groups and streams (illustrated in figure 5.9). Devices provide uniform abstractions for providers (sources) and consumers (sinks) of multimedia data, for example, sound capturing or video digitising hardware. Source and sink drivers are collected together to form source and sink groups respectively, each of which is controlled by a group manager
object. The group managers provide a level of abstraction over the underlying multicast and multidrop functionality. A computational object known as a stream object is responsible for organising the actual transport of information from sources to sinks and, in addition, is responsible for the selection and interposition of translators to provide filtering and mixing of the appropriate media type as necessary.
Continuous media has certain common characteristics. In particular, a given media type consists of discrete components or packets (a unit of audio or frame of video) which, when presented in a particular order within certain time constraints, represent a flow of information. This common or generic functionality has been singled out in the base services: each flow of information is regarded as a chain of media links. Operations common to all media types (and therefore all chains) include starting and stopping the flow of links and, in the case of finite length sequences, locating one’s position within the chain and seeking to a new position. These operations are supported by RM-ODP compatible chain interfaces which are exported by device objects. The interconnection of device objects is accomplished using endpoint interfaces which provide common interconnection functions for underlying transport management by the stream object.
/* Connect source and sink groups to stream */ ! {s_status} <- streamIf$ConnectSource(sourceGrpIf) ! {s_status} <- streamIf$ConnectSink(sinkGrpIf)
/* Set QoS Parameters */
! {QoS, s_status} <- streamIf$GetQoS() QoS.LinkSize = LinkSize;
! {oldQoS, s_status} <- streamIf$SetQoS(QoS) /* Prepare and commit stream object with QoS */ ! {s_status} <- streamIf$Prepare()
/* Prepare, commit QoS at source and start... */ if (s_status == s_okay) { ! {s_status} <- streamIf$Commit() if (s_status == s_okay) { ! {c_status} <- sourceChainIf$Prepare() if (c_status == c_okay) { ! {c_status} <- sourceChainIf$Commit() if (c_status == c_okay)
! {c_status} <- sourceChainIf$Start(0, c_asynch) }
} }
Figure 5.10 - Initiating a stream of media in the Base Services
The stream object provides an abstraction over the actual connection set-up and management. The stream management interface provides operations to allow groups of sources and sinks to be interconnected and supports a two-phase commit process which allows the communication to be aborted if the requested combination of drivers is unworkable (for either compatibility or connectivity reasons). A segment of code
illustrating basic connection establishment using a stream is shown in figure 5.10 (the platform’s distributed programming language is described in more detail in section 6.2.5.1). The abstraction provided by the stream object would enable alternative media transport protocols to be selected transparently. For example, the current implementation does not make use of multicast (due to operating system compatibility issues within the chosen platform). Multicast IP could be slotted in to the stream object without affecting the remainder of the audio conferencing architecture. Conference membership can change dynamically through the group management interfaces. Membership changes are propagated to the stream object via a call-back interface which allows it to re-configure. For more details on the complete Base Services architecture see [Coulson,92].
A subset of the original Base Services has been reimplemented by the author. The reimplemented services use the new platform and provide audio transport services for the communications module. More specifically, these services include: the stream object, group manager, and audio chain source and sink drivers (both for transient and persistent chains). In addition, the services have been extended to include support for multiple audio stream formats (see section 5.4.4).
5.3.3.3 Audio Conference Management
Each host within an audio conference requires an identical set of base service objects. Viewed as a whole, the object configuration is identical and symmetrical across all participating hosts.
Stream Audio Sink
Log Sink Sink
Group
1. Log joins sink group 2. Group informs Stream
3. Stream reconfigures audio delivery Audio 1 2
3
Figure 5.11 - Reconfiguring audio to add a persistent log
The objects are by default: a microphone driver, a speaker driver, a source group manager, a sink group manager and a stream manager. The driver objects simply provide two interfaces on to the audio sampling hardware of the host. The group objects allow dynamic reconfiguration of the conference (see figure 5.11), for example adding a logging device to record all outgoing or incoming audio traffic by
simply joining it to the appropriate endpoint group. The stream manager looks after the actual distribution of the audio packets.
The communications module makes use of the fact that the application, and hence the communications module itself, is replicated on each host within a conference. Since all membership changes are propagated to all reachable members by the group coordinator, the reconfiguration process is also distributed across all members, each taking an identical role. For example, adding a new member requires each communications coordinator to obtain the endpoint of the speaker driver of the new member and the inclusion of this endpoint within their local sink group. Since this process is executed by all conference participants in unison, the new member’s speaker driver simultaneously joins the sink group of all of the initial participants. The removal of a member is an almost identical process where the member’s endpoint is simply removed from the sink groups.