OSIPS 101: A Technical Guide to the Security Industry Association's OSIPS Data Models

By William DeVoe, Software Engineer

The OSIPS (Open, Systems Integration and Performance Standards) data models are breaking new ground in defining interoperability between components in traditional access control systems. The SIA Standards strategy of "breaking stovepipes" (described in previous SIA News articles) will lead to more choices for integrators, consultants and end-users.

But what are the OSIPS standards?

There are currently five OSIPS data models under development:

• OSIPS Framework (including connections, authentication and authorization, schedules, event reporting, and I/O points)
• Identity Management and Carrier (Cards and Credentials) Management Systems
• Access Control Role
• Digital Video Interface
• Access Point Controller

Each of these standards aims to provide a common interface for the components they model. For example, a host application would use a common set of operations and commands to interact with an Access Point Controller or Identity Management System. Components like a Digital Video Server can, and will, interact with devices managed by other data models.

A newly formed Standards subcommittee, the Security Applications Subcommittee, is working on providing standards that define the implementation of access control solutions using the OSIPS data models. The first standard under development will cover access control operations for vehicular gates. Other initiatives are under consideration and other standards are likely to come out of that subcommittee frequently.

 

Terminology

The OSIPS models are introducing several data model-specific terms that are necessary for full comprehension and usability. The basic terms are:

• Component: A product for which an interface data model is to be constructed. Components are logical constructs meaning that different physical devices may represent that one logical component. Similarly, a single physical device may support multiple SIA component interfaces.

   

• Consumer: An external device or system that uses the model interfaces to interact with the component. This term is not to be confused with a user of the system; a consumer is not a person.

   

• Element: The basic construct of a message. Elements relate to a specific OSIPS data type (like an OSIPS String).

   

• Interface: The collection of commands and actions (operations) that can be performed upon a specific component.

   

• Message: The mechanism by which components and consumers exchange information. Messages contain a header section and a content section. Interfaces define message constructs.

   

• Binding: A binding is a particular way of representing the data for a message and how that message is exchanged between two devices. All OSIPS data models are binding-independent, which means that while they define and describe the content and structure of messages, they make no statements about the actual implementation of those messages. More on bindings later in this article.

 

Model Basics

The OSIPS data models provide a mechanism allowing different systems to communicate and exchange data using messages. The heart of the OSIPS standards is a message composed of two elements — a header (which describes the data model version being used, the total length of the message, among others) and content (which contains the actual message data). Content is the "meat" of the message - it defines what information the consumer is requesting from the component, what values the consumer wants the component to use when configuring/provisioning its services, or what action(s) the consumer wants the component to take (via commands). Recipients of the message use the header to determine whether the message is intended for them and then use the content to determine the type of interaction desired. For example, the content of a message may contain a command to open a door or it may contain provisioning information for the component. These operations are collected into an interface that defines the commands and operations that can be performed on that component.

The models are binding-independent, meaning that any number of mechanisms may be used to encode the actual messages (e.g., XML, ASCII, ASM1, etc.) and transport them (e.g., RS232, TCP/IP, USB, etc.). The data models describe what elements are present in each of the messages, but make no specific statements about how they are implemented or the system topology to transport them. Standards that define binding implementations will be created and released following the publication of the OSIPS standards. SIA members and even non-members are encouraged to participate in this process as much as possible.

 

Standards Documents

Each standard has two main components — the interface data model and the conformity assessment. The interface data model describes not only the interface (operations) of a component, but defines any necessary structures or types that extend or differ from the basic OSIPS data model.

• Interface Model
  This section contains the specific messages that can be sent from a consumer to a component and component to a consumer. Similar to an interface in COM/Java terminology, the interface defines the operations that can be performed on the component, whether they are commands, requests or provisioning (configuration) messages.

   

• Message Content
  This section defines the structure of the content element of the SIA message. The elements here mirror the interface operations defined above and may be either specializations of existing message content types or may be entirely new content structures defined later.

   

• Special Structures
  Special structures define collections of message elements, other special structures, or both. They group elements and structures together to provide the information necessary to complete the action defined by the message. An example would be a structure that defines the configuration of a door, including door held time, unlock times, etc.

   

• Data Element Definitions
  These define all of the data model-specific element types. Any element that is used in a special structure or message content structure must be defined here. Elements are the smallest construct in the OSIPS data models and map to a very specific OSIPS data type.

   

• Enumerations and Validation Lists
  These define the complete lists (enumerations) and extensible lists (called validation lists) for various elements in the data model. For instance, a Boolean type may be enumerated as TRUE or FALSE — only those values are permitted. Validation lists allow extensions beyond the documented model definitions. An example may be the state of a door which could be "open", "closed", "locked" or some other state beyond these.

   

• Conformity Assessment
  The conformity assessment section defines how a particular product will be graded as adhering to the data model's constraints. Tests are documented and a prospective component is evaluated as to whether it meets the criteria for a conformity test or not. Scoring for individual tests are described in the tests themselves, but the normal score is a 1 (one) if the test passes and a 0 (zero) if the test fails or the feature is unsupported. Components need not comply with all tests to conform to the standard — they may ignore some functionality or partially implement it only.

Not only is the interface evaluated, but behavior as well. This means that components must not only support the actual messages (and reply appropriately) but must also support the resultant behavior of those messages. For example, a component may support schedule messages, but it must also support the behavior required or implied by those messages to pass some tests. Under no circumstances should a component fail completely (crash) as a result of receiving a message; it should report errors as appropriate instead.

 

Data Models

OSIPS Framework
This document contains all of the common data models. The Framework defines not only the basics of all OSIPS Standards data model, but also several data models that are shared between other standards. Included in the model are:

• OSIPS Framework Overview
  This describes the general construction of OSIPS data models.

   

• OSIPS Framework General Elements
  This includes basic messaging information, structures, and type definitions. The type definitions section also includes the types declared in the other sub-models found in the OSIPS Framework document.

   

• Component Connection
  This defines how consumers and components connect. Connections are initially made through a pre-defined mechanism and then a binding may be negotiated between the consumer and the component.

   

• Capabilities Exchange
  This defines what operations of the interface are supported and unsupported by the component. This is performed primarily by providing the conformity assessment report.

   

• Authentication/Authorization
  This defines how consumers provide credentials to access a component (authentication) and the services it provides (authorization). By design, some authenticated consumers may be able to access only certain services; these restrictions are captured via authorizations.

   

• Schedules
  These are a common mechanism for describing time intervals and schedule information. Schedules define time periods during which activity is allowed. Special dates are provided as a mechanism to override this behavior and prohibit activity.

   

• Event Reporting
  This defines the basic reporting mechanism of events from a component to a consumer. Events are component-generated messages and are sent to a consumer to notify it of state changes, command results, etc. Most event reporting structures are further detailed in the individual data models.

   

• I/O Points
  This defines the interface to input and output points. Both two and four state systems are supported in the model

The OSIPS Framework is also the repository for the actual element data types. The General Elements portion of the document contains all of the base type information for elements and all of the other data models eventually reference an OSIPS data type. Of particular note is that all of the numerical data types are represented as strings to avoid "endian" issues that arise in diverse controller architectures.

All data element types for the supplemental OSIPS Framework data models (schedules, event reporting, I/O points, etc.) are declared in the particular data model but are documented in the OSIPS Framework General Elements' Data Elements Definitions section. This means that while an OSIPS data model (e.g., Schedules Data Model) will declare a type (e.g., seStartTimeLocal), the definition (description and usage) of that type is located in the aforementioned section of the OSIPS document.

Digital Video Interface
The digital video standard defines the interface to a digital video device. It provides the ability to command the component to perform actions (such as pan/tilt/zoom control of a camera, extract video clips or single images, etc) on demand.

Included in the model are:

• Command Functions
  These allow the digital video device to act in the prescribed manner. This may include pan/tilt/zoom functionality or extraction/remote storage of video clips or still images.

   

• Device Presets
  These allow a consumer view preset configurations on the digital video device.

Identity Management/Carrier Management System
This standard focuses not only on collecting and managing identity information and issuing cards (called carriers), but also on the process of collecting and validating information about the person to whom the carrier is being issued.

Included in the model are:

• FIPS 201 and PIV
  A major responsibility of the standard is to address the HSPD-12 and FIPS 201/PIV standards produced by the U.S. government. Particular emphasis has been placed on ensuring that requirements stated by these documents are met by this standard.

   

• Carrier (Card) and Credential Container Information
  Credential containers provide specific requirements about how the credential information is stored on the carrier (either physically printed on or logically within the carrier).

 

Access Control Role

The access control role acts both as a repository of event and alarm information from the components in the system as well as a provisioner of components (including access point controllers and digital video devices). In a traditional access control system, this role is somewhat synonymous with a head-end database.

Included in the standard are:

• Accessible Element Definitions
  These define a traditional "area." Accessible Elements are the resources that can be accessed with valid credentials (doors, etc.).

   

• Access Rules
  These define how credential information is validated for access to an accessible element.

   

• Event and Alarm Repository
  This is a repository of event and alarm information from components.

   

• Access Point Configuration
  This provides provisioning data to an Access Point Controller about Access Points.

Access Point Controller
An access point controller is in many senses a traditional access control panel. The access point controller uses information from an access control role to manage the access points, access rights and schedule information. It must also use information provided from an Access Control Role system to correctly identify credential information. At a basic level, the Access Point Controller decides whether to open the door or not.

Also included in the data model are:

• Access Points
  An Access Point is a collection of internal and external devices that allows a person to gain access to a resource. A standard usage would be a door where several devices interact with a reader to allow a Credential Holder ingress or egress through that door.

   

• Communication Ports
  This allows a consumer to configure how an Access Point Controller communicates with internal and external devices. Internals devices may include card readers while external devices could include a Digital Video device.

   

• Carrier (Card) Read/Write Data
  This allows a consumer to read data from or write data to a carrier/card. An example would be changing the expiration date on a card, making it unusable on another system.

Security Applications Standards
The Security Applications Standards subcommittee has been tasked with creating standards that define the operation of specific applications or implementations using the OSIPS data models. For example, an access control vehicular gate application/implementation may require use of all of the OSIPS data models being written. The standard would specify which data model constructs should be used for the various types of implementations. This subcommittee will be striving to produce clear, concise and complete standards, easing understanding and adoption of the OSIPS data models by consultants and the government community.

 

Implementing an OSIPS Data Model

Implementing a standard requires a familiarity not only with the specific data model for the component but also any relevant sections of other normatively referenced data models and, of course, the OSIPS Framework. To grasp a basic understanding of a data model, this level of competence is not required, but for actual implementation, it is a necessity.

Within each data model document, the flow is top-to-bottom. Reading through the document from front-to-back is one way to gain ever-increasing understanding of the data model, but for quick comprehension, the following order is highly recommended:

1. Skim through the component interface. This will provide some context for what kinds of operations are supported by components supporting this data model. Monikers should help identify specific command actions. The basic list is:
   1. AD for Add
   2. AU for Add/Update
   3. CM for Command
   4. DD for Delete Data
   5. DR for Data Item Request (consumer to component)
   6. LR for List Request (consumer to component)
   7. RD for Report Data (component to consumer)
   8. RL for Report List (component to consumer)
   9. RS for Reply Status
   10. UD for Update Data

    

2. Skim the message content elements. Many times these are specializations or extensions of the basic OSIPS message content structures. Detailed analysis isn't necessary beyond being familiar with the specializations.

    

3. Review the special structures. This section is perhaps the most important as it clearly defines the content and structure of the content portion of the messages. These may strongly impact your implementation. The special structures are often very onion-like — one level wraps a deeper implementation which wraps another. Delving down into these structures to the individual elements is necessary to understand what information is being exchanged.

    

4. Review the data element type definitions, which describe the meaning of the elements defined in the special structures and message content sections. Many times the definition of an element may differ than what may be expected simply from the name. All model element types refer to OSIPS general element types. Remember that for the OSIPS Framework sub-models, the data element type definitions are defined in the OSIPS Framework General Elements section of the document.

    

5. Review the enumerations and validation lists.

    

6. Finally, skim the conformity assessment. This is what a particular product will be graded against for publication via capability exchange.

This investigative series closely mirrors the document layout. The message content and special structures are absolutely vital to understanding not only the "letter" of the standard, but the intent.

Once a basic familiarity with the specific data model is gained, implementers should review the OSIPS Framework as many of the elements defined in the specific model reference the global elements. The sub-models in the OSIPS Framework are closely coupled with the independent data models. For example, the Access Point Controller data model uses the I/O Point data model and the Schedules data model in implementing some of its capabilities.

Following this first pass, an in-depth review of the conformity assessment section is desirable. This section will explicitly state what criteria must be met in order to claim compliance with that functionality. The "report card" generated as a result of this conformity analysis should be provided to product integrators so that they can easily evaluate the functionality available to their systems. Note that these conformance tests not only test specific adherence to interface and type but to behavior. When a consumer provisions a component, it needs to expect a certain behavior from that component. This again integrates not only the "letter" of the standard, but its intent.

When implementing a system, it is not necessary that the design of the system mirror that provided in the data models, but such harmonization would simplify understanding and implementation.

 

What Is Mandatory?

This is a somewhat difficult question to answer as a manufacturer can choose what to implement and what to ignore from a specific data model. The simple answer is: as much as is desired by a manufacturer/vendor. The more complex answer is that components, to be "good OSIPS citizens," should support as much as possible to allow for maximum flexibility and usability.

There is a baseline implementation that must be met in order for the component to be able to communicate with other OSIPS-compliant devices. The minimum required is:

• OSIPS Framework General Elements (found in OSIPS Framework)
  A component must support at least the basic messaging framework and types.

   

• Component Connection (found in OSIPS Framework)
  A component must support connections between consumers and itself and, if required, between itself and other components.

   

• Authentication/Authorization (found in OSIPS Framework)
  A component must support the authentication model elements; the authentication elements may not be necessary or valid for certain implementations.

   

• Capabilities Exchange (found in OSIPS Framework)
  Components must be able to provide information about their capabilities to consumers.

   

• A binding (found in to-be-published binding standards)
  Components must support some mechanism of communication.

   

• Desired data model-specific interface elements
  Components may support as little or as much of the data model as required by its implementation, but some models may require some mandatory constraints; these should be documented in the Conformity Assessment.

Beyond this minimum, the simple answer above suffices for most implementations. The conformity assessment will inform others of what interface elements are supported by components. The component must be accessible, however, and the list above supports the bare minimum for connectivity.

 

Bindings

As mentioned previously, the data models are binding-independent. The SIA Standards Committee intends to provide standard bindings as they become available. If a desired binding (for example, XML via RS232) is unavailable, the SIA Standards Committee strongly recommends that manufacturers and integrators work with the committee to create and formalize that binding. The standards committee will also review any vendor-supplied binding definitions as proposals for a formalized binding definition. Only one standard would be provided for a given binding, meaning that any implementations that support that binding would support the particular grammar defined in that binding standard document.

The bindings truly are "where the rubber meets the road" in the data models - it is the form and protocol by which messages are sent. As a result, supported bindings heavily impact how broadly a particular product may be accepted in the marketplace. While it is not expected that a single product provide all possible bindings, an evaluation of what may be perceived as "regular" or "common" bindings should be performed by manufacturers and integrators.

 

Manufacturer Extensions

There are times when a manufacturer may desire a component provide functionality that is not documented or that extends the functionality of a data model. In this instance, manufacturer- and vendor-specific extensions are available. Manufacturers and vendors can submit to SIA Standards staff a request for a model prefix that will be used to identify their additional functionality. This model prefix (used in the message header) will uniquely identify that manufacturer's extensions. Manufacturers and vendors should use the same prefix for any functionality they add, regardless of the data model it extends — the prefix identifies the manufacturer, not the functionality.

A data model describing the new functionality should be published by the manufacturer to interested parties. It need not be submitted to SIA to be used. These extensions documents should meet the requirements for an OSIPS standard (in form and function) and manufacturers and vendors providing these should therefore have a full understanding of the OSIPS data model structure and definitions. Manufacturers and vendors should also consider contributing these extensions to the subcommittees and ad hoc committees that oversee the data models so extended if they wish to see these extensions more widely adopted throughout the industry.

 

Summary

Implementing a data model is straight-forward task, but it may require some vendors and manufacturers to re-evaluate how they provide interfaces to their products. It can also be perceived as a daunting task as it requires a level of familiarity and competence with not only the standard relating to the product, but with other data models as well. The OSIPS data models are a departure from the current security industry model — that of proprietary or arbitrarily created interfaces to components. In the new world provided by OSIPS, components can more readily integrate with other components, devices with other devices, and systems with sub-systems and other systems. The ability to provide customers with the best-in-class devices at all levels will result in more secure, more reliable and more flexible systems.