The ALiS version 1.2.002
This documents describes the functionality supported by ALiS version 1.2.002 The document is meant to provide insight to non technical staff into the functionality, the possibilities and restrictions of the ALiS standard. This document does not cover all implementation details, the actual technical description of the standard is given in the document “ALiS Server Specifications Version 1.2.002”, in the case of contradictions between this document and the “ALiS Server Specifications Version 1.2.002”, the specifications document prevails.
The ALiS standard is a standard that describes the way information can be exchanged between telemanagement hardware devices (Outdoor Lamp Controllers or OLCs) for public lighting and back office systems from which the public lighting is monitored and managed. The purpose is to enable interoperability between systems from different vendors. The standard can be used on different levels: in the case the telemanagement system uses a segment controller to manage a segment of OLCs, the communication can be established between the segment controller and the third party back office system. Also, communication can be established from the OLC vendors’ back office to the third party back office.
The ALiS standard describes the way an ALiS server should be able to handle requests and the data that should be returned using this requests. ALiS does not define the type of security the vendor should use to protect the API from unwanted usage or to manage users and their rights.
The responsibility and choice of the type of security used is entirely up to the vendor. Any communication or documentation needed to implement an ALiS server using the chosen security method should be supplied by the vendor.
The ALiS standard aims at supporting interoperability for the daily use of telemanagement systems. This means that the standard supports data exchange for monitoring and managing the systems, but not for configuration, setup, firmware updates or other setup of maintenance operations.
The ALiS standard is meant to provide interoperability whilst maintaining the possibility for vendors to compete on quality, features, level of implementation and the way information is collected and processed. Therefore, the ALiS standard does not prescribe the data collection quality, frequency, accuracy, etc. The standard describes how the exchange of information and requests should be handled, much like a language: it describes how we exchange information, but it doesn’t describe the quality, frequency of how this information should be collected.
To enable maximum extensibility per vendor, vendor specific data may be defined. Data returned will follow the standards deﬁned in the specification document, but can be freely supplied. This enables the vendor to supply vendor speciﬁc information about the groups or data that currently is not deﬁned as ‘standard’ information in the normal request.
Note*: using this notation allows easy extensibility at this moment per vendor. The goal however is that during the evolution of this document the vendor speciﬁc data will be used to deﬁned new ‘standard’ ﬁelds within the regular requests.
OLCs will run specific dimming scenario’s during normal operation. These dimming scenario’s run autonomous as long as no other commands have been given. Commands that intend to temporarily overrule de dimming scenario are called overrides (override is set to ON). When override is set to OFF, the system will fall back to its normal dimming scenario.
The following Controlling lights commands are supported:
- Override command to switch lights ON and to a specific light output (1-100%) on group or light level
- Override command to dim the lights to a specific light output (0-100%) on group or light level
- Override command to switch lights OFF on group or light level
- Not every vendor has the possibility to turn a system OFF in the way there will be no power on the system. In the case where the POWER of the segment controller can be turned ON or OFF using ALiS server a request can be made to turn OFF the POWER if that is not the case, command OFF means the light output will be set to 0% and the ON command sets the light output >0% light output.
CONFIGURING DIMMING SCENARIO
Dimmingscenarios can be configured either on group level (recommended) or light level. Either case a light should always have a minimum of one defined dimming scenario (being one moment of time in a week where the LightOutput is defined). This is needed to define the state of LightOuput to return to after OVERRIDE is set to OFF.
If a light is part of a group where a dimming scenario is defined then a dimming scenario on the specific light is not needed.
A dimming scenario is a repeating scenario for a week consisting of entries per day of the week (numeric) containing dim entries per day defining the time and light output at that given time.
ALiS makes it possible to request the current (or latest depending on hardware) status of segment controllers, lights and groups within the system. This enables implementing software to retrieve the status, light output and such to (for instance) display on a map or list.
For definitions of specific status data implementations, a list will be published by the ALiS foundation. Any new definitions or implementations should be shared with the ALiS foundation and will be updated in the peripheral definitions list.
Notifications are used to show if there are either (important) activities or alerts and a specific message describing the type of notification (for example a lamp failure). Using this request it is possible to act upon these notifications by for instance adding coloured markers to the maps showing the lights or if needed sending alert e-mails or text messages to report problems to the administrators or contractors.
For definitions of specific notifications implementations, a list will be published by the ALiS foundation. Any new definitions or implementations should be shared with the ALiS foundation and will be updated in the peripheral definitions list.
Within the ALiS standard, it is possible to define peripheral devices. These are devices that may be installed on lamp posts for certain purposes such as motion sensors, hydroscopes, etc. Peripherals can be defined, monitored and controlled using the ALiS standard.
For definitions of specific peripheral implementations, a list will be published by the ALiS foundation. Any new definitions or implementations should be shared with the ALiS foundation and will be updated in the peripheral definitions list.
It is also possible (implementation is vendor specific) to retrieve log data from the different elements (segment controllers, lights, peripherals). This data can be used for making report or running statistical analysis on the system. Examples of log data can be energy consumption, burning hours, temperature, etc.
For definitions of specific logging implementations, a list will be published by the ALiS foundation. Any new definitions or implementations should be shared with the ALiS foundation and will be updated in the log definitions list.