Page History

...

There are no alarm types for sequences of values, because the alarm can only be triggered by a single value. This means that <type>Seq property may raise an alarm and the client may subscribe to the alarm by passing Alarm<type> CORBA object, but the callback is invoked for each element in the sequence. For example, if 4 values in a sequence go over a certain limit, the callback will be invoked 4 times.QUESTION: This is how <type>Seq is implemented in C++ (I just checked the code and did not test its actual behavior, so it could be wrong), and I added these sentences here. However, I think it is not a good implementation because, from the view point of the client, the client cannot know which element raises an alarm because Completion or CBDescOut structures do not have a field which holds the index of the element.
I personally think that the alarm is not necessary for Seq type. If the device server developer needs to define an alarm for Seq type, he can extend BACI property to support alarm by himself and the alarm condition should be defined by the developer (e.g. if average of all elements go over a certain value). I cannot come up with a good usage of the current alarm implementation for Seq types in C++.
My suggestion is that we explicitly state that BACI specification does not officially provide alarms for Seq types. This means that the client may still use the existing C++ BACI Seq type properties, but it won't be officially supported and jBACI won't also implement the alarms for Seq types.
Is this a reasonable solution?
A process subscribes to alarms via a method that is part of all RO (read-only) properties. Following is the code from the ROdouble property; for other types all occurrences of double have to be replaced correspondingly:
Subscription new_subscription_Alarm(in Alarmdouble cb, in CBDescIn desc);QUESTION: The method name was formally new_subscription_Alarmdouble, but as far as I see baci.idl, its name was new_subscription_Alarm and the method name is the same for all types. I think it is better to modify this specification in this case. Is it OK?
Note that, even if the same method name is used for different types, type checking will be still done by the compiler by checking the type of the first argument (Alarmdouble in this case).
Only properties of type RO have alarms, as RW properties should not even be able to set values in the alarm ranges. The method returns a Subscription object, which has to be used to destroy the subscription to the alarm events. The Subscription object is the event source interface. It is also the superclass for monitors (see next section).
interface Subscription{
// temporarily suspends dissemination of event callbacks.
void suspend();
// resumes dissemination of callbacks. Ignored if no previous suspend occured.
void resume();QUESTION: For monitoring purpose, if resume() is called after suspend, when shall the first timer trigger be invoked? Immediately after resume() invocation? Or, the time shall be aligned to start_time? If I were a client developer, I would expect that the timer trigger is always aligned to start_time so that the callback is called, for example, at 0:0:0, 0:0:10, 0:0:20, 0:0:30, … if we set the time interval to 10 seconds.
The same discussion goes for the case where the time interval is changed by set_timer_trigger().
// stops dissemination of event callbacks and releases all resources.
void destroy();QUESTION1: Is there any specification (in CORBA or ACS) about what the servant should do when a method is called after destroy() is called. This could happen when a client has several threads, and one thread may call destroy() and, right after that, another thread may call another method.
QUESTION2: Is this destroy() method a standard method to destroy a remote CORBA object? If so, how CORBA ORB responds to the client when a remote object is destroyed (or being destroyed).
QUESTION3: Is there a good document about the lifecycle of the dynamically created CORBA objects. Particularly, I would like to know how such CORBA object shall be implemented in Java (e.g. what methods should be implemented to support the lifecycle of CORBA object and what assumptions can be made to implement those methods). For Java implementation, I am also wondering how the corresponding Java object will be removed from the heap (e.g. when CORBA ORB releases the reference of that Java object?).};

A process subscribes to alarms via a method that is part of all RO (read-only) properties. Following is the code from the ROdouble property; for other types all occurrences of double have to be replaced correspondingly:

Subscription new_subscription_Alarm(in Alarmdouble cb, in CBDescIn desc);

Only properties of type RO have alarms, as RW properties should not even be able to set values in the alarm ranges. The method returns a Subscription object, which has to be used to destroy the subscription to the alarm events. The Subscription object is the event source interface. It is also the superclass for monitors (see next section).

interface Subscription{

    // temporarily suspends dissemination of event callbacks.
    void suspend();

    // resumes dissemination of callbacks. Ignored if no previous suspend occured.
    void resume();

    // stops dissemination of event callbacks and releases all resources.
    void destroy();
}; 

A very important feature of alarms is that an alarm event is sent immediately after the client has subscribed to the alarm and when a server reconnects to existing client subscriptions after a restart. The event is used to notify the client of the current alarm status. If everything is OK, the alarm_cleared() method is called, otherwise the alarm_raised() method returns the code for the current alarm. The reason for this requirement is that when a client subscribes freshly to an alarm, it does not know, whether the property is in normal or alarm state. As alarm events are sent only upon changes of alarm conditions, the client might never know that the property has already raised an alarm and that further operations on the property or its device should be restricted.

This requirement is particularly useful in two cases:

...

};
On creation of a monitor, the only trigger present will be the timer trigger. Calling the set_value_trigger() method determines the behavior of the value triggerTODO: It implies that both timer trigger and value trigger can coexist at the same time. Make a test case to check if the coexistence of two triggers work properly.. The enable parameter determines whether the value trigger is active or not . Value 0 assigned to value trigger means that a notification should be sent on every change of the monitored value. This is very dangerous as it could flood the network. Therefore, there is a characteristic of the property, similar to min_timer_trigger, called min_delta_trigger, which specifies the minimum allowed threshold for value change. Invalid values (out-of-limits) are treated as valid extremes (a delta trigger below min_delta_trigger is treated as min_delta_trigger).
The interval at which the callback is invoked by the monitor is determined by the default setup for the specific property, which is typically in the order of one or several second. The ACS cannot guarantee, however, that the requested time intervals are met by the control system. The given values correspond just to approximate orders of magnitude. It can happen furthermore that not all control systems are able to respond in the order of milliseconds. The values should be therefore taken as a lower limit for the time between two consecutive monitor callbacks.QUESTION: This implies that, for example, if the timer trigger interval is set to 1 second and the first timer trigger is invoked at 0:0:0.000, the next triggers would be invoked at 0:0:1.001, 0:0:2.003, 0:0:3.00,5, 0:0:4.006, … (here I assumed there would be 1 ~ 2 ms delay for each trigger). In 5 minutes or so, the timer trigger would be invoked at 0:5:0.521. In the end, the time trigger would be invoked 3594 times during one hour.
Is this really what the client expects? If I were the developer of the client program, I would expect that the timer trigger is invoked 3600 times every hour, and the invocation time is aligned to 000 millisecond for each second (I guess create_postponed_monitor() exists for that purpose).

Properties

Having defined all concepts, we can now put them together into the most important interface of BACI, the property. The BACI specifications define only the core method of the root property interface, meaningfully called Property. For ACS, we have to define concrete properties that will be used to control and supervise all points of ALMA. In order to keep the interface definitions reasonably simple, we have kept the number of different property types small.
Properties are the basic entities that are manipulated by the control system. For a discussion on the meaning of properties and their relation to Components see the BACI white paper\[6\]. Two basic flavors of properties exist: RO = read-only (e.g. encoder position, device status) and RW = read-write (e.g. power supply voltage, pointing coordinate). In addition, properties have a certain type like double, long, string, etc.
!worddav254deeaa31b662cce7058d7e95ec63b1.png|height=305,width=389!
_Figure 1: Inheritance diagram for Acs::PdoubleSeq_
For the normal user of ACS, the object hierarchy of properties has little meaning (see figure 1). It may be confusing at best, because the only properties that a Component actually contains are of the type RO and RW. However, the hierarchy is very important for the code generator (not yet provided for ACS) and to account for all BACI concepts, which include groups of Components and others. In this document, we will simply state and explain all methods that all Properties have and then jump directly to the presentation of RO and RW properties.

Methods and Attributes Common to All Properties

The following methods and attributes are common to all properties, because they come from the interfaces higher up the inheritance hierarchy (CharacteristicModel, Property, TypelessProperty). They can be common, because they do not depend on the type of the property value. A normal client would use only those in italics. The others are mainly used by generic clients, like the Object Explorer, and the Abeans libraries that provide Java Beans components for fast client development.
readonly attribute string name; // The fully qualified name of the Property
\\
//generic access to characteristics, even those that are not declared in the IDL
any get_characteristic_by_name(in string name) raises (NoSuchCharacteristic);
\\
//returns a sequence of characteristic names that match the regular expressions
//reg_exp. It returns a sequence of length 0 if no match is found.  
stringSeq find_characteristic(in string reg_exp);
\\
// The name of the parent Component
readonly attribute string characteristic_component_name; 
\\
//Returns a PropertySet object containing all characteristics of the Property.
CosPropertyService::PropertySet get_all_characteristics();
\\
readonly attribute string description; // the description of the Property
readonly attribute string format;      // the format for printf in C-syntax 
readonly attribute string units;       // the units of the Property
readonly attribute pattern resolution; // a bitpattern of significant bits
\\
// Publish the value of the property.
// This method is meant to be called when the value of this property must be
// archived/monitored in relation to a change or error of another monitor point.
void publish_now();
\\
Some more explanations on the definitions: The main BACI components, such as Component and Property are named: they have a name, which the manager (see \[7\]) can convert to object reference if the client has the correct access level (only for Component). A Property cannot exist on its own - it is always a read-only attribute of a Component and thus knows the name of it. It does not keep an object reference to the Component for security reasons. The attribute pattern resolution is actually a bit pattern representing the significant bits of the word carrying the value. It is useful also for returning the resolution of analog-digital converters in case of numeric properties.

The Interface for Double PropertiesTODO: compare the contents of this section with baci.idl and update this section accordingly. Or, maybe we can copy the contents of this section to the inline documents in baci.idl, and put the link to baci.idl so that we don't have to worry about the consistency between two separate documents.

...