Compelling Reasons for Common Programming Language (CPL) Do you have any?

Winston Hetherington, Owner B.A.S.S. Consulting Servces

What would make you think seriously about going to a Common Programming Language (CPL).  As an Owner Operator Representative (OOR) responsible for maintaining multiple buildings or campus, would you be enthused by the thought of having all of your building automation systems (BAS) controllers use the same control application logic? Or graphic programming that is easier to use? No more dealing with legacy scripting or unintelligible code, presently in various products.  Fantasy or reality?

For those who may presently be burdened by a similar responsibility but also facing issues of obtaining and retaining the additional technology and knowledge skills to maintain five or more different BAS products, each with their own proprietary implementation of Control Application Logic (CAL), CPL might seem like wishful thinking.

Obviously technologists/technicians working as OORs require a different skill set from those working for contractors or manufacturers. The OOR personnel have the added responsibility of meeting owner’s expectations and the overall performance of the facility they work in. Often they are behind in their training for new products and technologies as owners often find training a burdensome cost.

In general, contractor personnel are motivated to complete specific tasks and to move on to a new project as quickly as possible (considered good for business). It is important to note this distinction. To the contractor personnel CPL is not a big issue; typically they are called to perform installation/service for one product or product line for which they have received the necessary factory training. They are not challenged by which CPL is used.

Contracting with funding from public sources typically limits the specifications for new and retrofit projects to competitive bidding processes and precludes naming BAS suppliers even to the  determent of the maintainers of the new BAS. Invariably the outcome of the new contract is the introduction of a new challenge for the maintainers.

The dream of the maintainers might be resolved by the introduction of CPL. Once defined and made available for production use, new products installed using CPL would match existing controller CAL after upgrade) internal workings. Training, experience and systems applications could be applied to the new installations. It’s a win-win situation for OOR maintainers.

[an error occurred while processing this directive] At this point the names, appearance and methods are all open for discussion, so what are your ideas about how CAL should look or feel. How smart should it be? Should the codes be generated auto-magically?  Example. if sensor input is selected should an output list be shown to select from? Should it also bring up a PID equation to implement? What would be helpful?  Should it also validate the line just completed, checking for syntax, structure and/or field sensor input/output? Would it be helpful to view logic in real-time to verify values are being processed as expected? Some existing proprietary implementations have some of these capabilities. It is essential to advance our industry that good things need to be kept and not lost in the standardization process.

Interest is growing, ideas are being put forward. A forum has been proposed by Joel, now spread the news so that more Owner Operator Representatives can have a voice in a significant change for the industry.

Imagine also the potential if a common Point Identifier text were to be included!  Mixed Air Temperature would always “MAT”

Follow other forum discussions on AutomatedBuildings LinkedIn – How can we achieve an Open Programming Language for Building Automation Systems?

also on BACnet LinkedIn  Who Cares About A Common Programming Language?

One of David Fisher's comment “What we are talking about is a BACnet-centric framework that allows you to do the same kinds of things that you could do with Tridium, but in an open manner that exposes the programming, configuration and toolset to all. But hopefully a lot easier to use :-) “

About the Author

Winston Hetherington B.B.A, Life Member ASHRAE, Fellow BACnet International
Building Automation System Specialist

Winston is a Life Member of ASHRAE and served as active member of the ASHRAE SSPC-135 BACnet Committee. he remains active in the BACnet community through the BACnet International Organization, Education Committee.

Winston served as Technical Manager for the Canadian Automated Building (CAB) Protocol development which was a Government of Canada initiative, Published in 1994.  During his tenure at Public Works and Government Services Canada (PWGSC) he was involved with maintenance of the National Master Specifications for Section 15900 and the creation of new section 17000 which latter became sections13830 -13849. Over a twenty year period these specifications experienced major changes going from pneumatic systems to microprocessor based systems. During the last 8 years he had principal responsibility for updating sections 13830 – 13848 of the National Master Specifications. Winston served as PWGSC’s representative on the Intelligent Building Technology Road map Steering Committee over the duration of the project and the publishing of the report 2001.