L ON M ARK ® Profiles - What Works Alex Chervet Echelon Corp.

2 Agenda How to build a closed proprietary system Why be closed? How to build an open system Why be open? Using open standards in a closed or proprietary fashion

3 Agenda (cont.) Using open standards in an open, interoperable fashion Network Variables Creating and publishing open interfaces Open interfaces are not enough –Being a good network citizen

4 How to build a closed system Use special hardware –“Homebrew” bit-shifting interface Use standard hardware in a non-standard way –RS-232 running at 5500 baud Create your own protocol (e.g. AlexTalk) Use a standard protocol as the transport but create your own unique message format –Application messages instead of NVs

5 Why be closed? It allows you to make simplifying assumptions about your system –My system will only ever have 10 devices, 9 of the devices always talk back to the master, … Closed systems make it more difficult for your customers to choose one of your competitors as a future supplier or for service needs

6 How to build an open system Don’t do the things listed on slide #4 Publish your interface Don’t use system specific definitions –Up / Down / Pass / Nudge chime Don’t force people to adopt your semantics –Use L ON M ARK definitions, not your own. Allows a single set of semantics to apply across industries

7 Why be open? Your customers are demanding it! Using open systems allows you and your customers to assemble “best of breed” products into the final design Open systems provide a platform that is easily leveraged into the next generation of your design –The software interface that was supplied to customer “A” is the same interface that will be asked for by customer “B”.

8 Why be open? (cont.) Open systems offer multiple sources of supply and greater economies of scale - which lead to lower costs You can react quickly to customer needs by utilizing off-the-shelf products –May require a business shift from pure manufacturing to a combination of manufacturing and system integration –Only manufacture parts/components where you add significant value - focus on your core competencies

9 Watch out for these people! Using open systems in a closed or proprietary fashion –Usually motivated by the belief that they can “lock-in” their customers Example –A manufacture might claim they are “open” because they use LonWorks as their network protocol. However, if the content of the LonTalk packets is unpublished or controlled by a single vendor, the system is not truly open

1010 What L ON M ARK is about interoperableUsing open standards in a truly open, interoperable fashion –Although the concepts set forth by L ON M ARK could be applied to any networking technology, L ON M ARK profiles assume an IEEE-1473L implementation TM

1 Command Vs. Information based systems

1212 “Command-Based” systems Motion DetectorLamp ON/OFF Command The decision to turn the lamp ON or OFF is made in the motion detector. This system applies a master/slave approach to control. The master (motion detector) commands everything in the system.

1313 Adding a device is difficult! Motion Detector Lamp ON/OFF Command Alarm Bell If the motion detector is commanding everything in the system, adding a new device (the Alarm Bell) requires a software change in the motion detector. The motion detector now has to send commands to the alarm horn as well as the light! Sound Alarm Command Alarm

1414 “Information-Based” systems Key Pad Key Code Control Knob 0% - 100% Motion Detector Motion Lamp Brightness Room Occupied Alarm Bell Sensors “publish” information, and actuators “subscribe” to the information which interests them! Feedback Alarm Arm / Disarm Intruder

1515 “Information-Based” systems Key Pad Control Knob 0% - 100% Motion Detector Motion Lamp Brightness Room Occupied Alarm Bell Key Code The details of how devices are connected or “bound” together are abstracted by LonWorks. Binding can occur at any time without affecting the application program in the device! Feedback Alarm Arm / Disarm Intruder

1616 Defining an open software interface

1717 Use Network Variables SNVT_angle SNVT_lev_cont SNVT_speed SNVT_temp Network Variables (Semantics defined by L ON M ARK ) Temperature, Degrees Celsius, , 0.1 degree Speed, Meters/Sec, , 0.1 m/s Continuous Level, Percent, %, 0.5% Phase/Rotation, Radians, , rads Network Variables provide semantic information about their data Connections can be defined at any time

Room Temp Set Point Temp Set Point Temp Sensor (Made in USA) Setpoint Display (Made in Canada) Boiler System (Made in Europe) Engineering units are defined

1919 Object Name & Number Mandatory Network Variables Optional Network Variables Manufacturer Specific Network Variables Configuration Properties Hardware Outputs Hardware Inputs Config Props L ON M ARK functional profiles

2020 Sample Profile “Chime”

2121 Chime - proposed elevator profile SNVT_Chime nviChime SNVT_lev_cont nviChimeVol Configuration Properties Mandatory Network Variables Optional Network Variables Object Type 4 Audible Signal “The chime object interacts with the elevator control system or other L ON M ARK node…” “The chime can output one of five signals: fast tone for floor passing, one tone for up, two tones for down, nudging, fire service.”

2 The Code network input SNVT_chime nviChime; typedef enum { up = 1, down = 2, pass = 3, nudge = 4, fireserv = 5, enable = 6, disable = 7 }(S)NVT_Chime; network input SNVT_lev_cont nviChimeVol; Proposed SNVT contains elevator specific enumerations! Enable/Disable has nothing to do with the actual tone. This should be handled using a third NV. Possibly okay, but why not use SNVT_Sound_db, it was meant to define audio volume.

2323 Configuration Properties Mandatory NVs Optional NVs Object Type 4 Chime - a better solution SNVT_Switch nviPlay Configuration Properties Audible Signal SNVT_sound_db nviVol SNVT_Switch nvEnable SNVT_Freq nviFreq SNVT_Millisecond nviDuration SNVT_Switch nvEnableFb