Page History

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.

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.