Cover

XLT Information

XLT Design

Translates Legacy Supermarket systems from the last 25 years.

Translates to a common “Generic Supermarket” structured format.

Communicates in a Random Access protocol.

Communicates by Ethernet/Internet. Hi-speed access anywhere in the world.

All screens are Web Based. No-one needs ‘special’ software to access a system.

When new sites/equipment are added, no one has to learn a new program.

All passwords and users are centrally controlled. When someone is put on or off the system, it happens in seconds for all sites.

All systems are “Self Learning”. No one spends days of engineering time ‘developing’ the site, with guaranteed mistakes to be made.

No-one else in the Industry has yet done this.

XLT System

At Customer Headquarters or on the

road

Web Server

@ACIWebs

Central Server

Customer WWW

Uses ordinary Web Browser (IE6, etc)

LegacyController(s)

XLTWireless ??

Legacy I/O

VPN @ Corporate IT

Corporate Network

DSL Line

In Store

OEM/Value Added

Group

Alarm Monitoring,

Energy Monitoring,

Etc.

Uses specialized toolsNew I/O,

Meters, etc

XLT Alarms, Setpoints, and/or Energy

Alarm and/or Energy Monitoring

Alarm Server

@ACIWebs

Central Server

LegacyController(s)

XLTWireless ??

Legacy I/O

VPN @ Corporate IT

Corporate Network

DSL Line

In Store

Text XML Http POST

Reasons for the XLT

Supermarkets want the latest technology. Each and every energy or monitoring manager wants the latest wrinkle, the most productive algorithm, etc. His only problem is paying for it, budgeting it, and justifying it. (Those aren’t all the same thing)

No Supermarket wants to be captive. No-one wants to be ‘locked in’ to a specific system in such a way that they have no choice about what equipment they use, when they have to budget it, etc.

When new sites or equipment are added, no one wants to have to learn a whole new way of doing things.

When new equipment is planned, no one wants to have to leave older stores by the wayside, sometimes for years, while everything is upgraded.

When new equipment is used, the energy/monitoring manager expects the inherent system to make his life easier and/or cheaper, not to require more effort or cost more.

Reasons for working with Zero3 and the XLT

Most customers will never change out ALL their sites to a particular brand of controller. Most customers have a collection of Legacy equipment. Some of it works well, and isn’t in imminent danger of being obsolete. Some of it is no longer serviceable, for good reasons. Some of it was modern stuff, bought in an attempt to determine whose equipment provided the best service. The sales arena for controller manufacturers is really in the second area, and sometimes in the third. The XLT offers the customer the opportunity to bring all the equipment he has spread around into one common, highly usable network, and allow him to plan the replacement/upgrading of his obsolescent in a reasonable and affordable way.

No-One wants to relearn. No-one wants to go from one comprehensive system to another, even if the services level is the same or slightly better. The learning curves are too steep in today's labor environment to make that step. If the ‘New’ system doesn’t offer as much, they certainly don’t want to go there.

No controller manufacturer wants to become just a commodity. The modern controller offers a host of features previously unavailable. Even in a comprehensive communications system, there are ways of advertising and expressing the differences, without destroying or degrading the common approach needed to make the XLT concepts workable. The XLT now puts a small note on the bottom of the screen saying ‘ComTrol’ or ‘Danfoss’. That could easily be changed to a more visible logo, and clicking on this logo could lead to a couple of web pages extolling the virtues and features of the modern device, and/or a help screen oriented to that device. Zero3 would prefer to work with the Controller Mfr, and let them structure their own screens in this area.

The critical difference will be either cooperation or challenge. The XLT screen operations are just the tip of the iceberg. The XLT Expert system, the Query Engine, the Energy Manager, and the Global Change Manager will be the elements of this design that make customers want to buy in to the XLT. The screen pictures are pretty, but the others offer the possibility of real savings for both the customer and the OEM doing the monitoring. The tide in the supermarket industry is running toward services and management. That is going to eventually require an approach like the XLT. The recurring revenue stream from this management operation will inevitably supplant controller sales as a smart companies mission.

The key ingredient in cooperation will be working together for a common goal, not dominance by one party. For instance, it is entirely possible for future models of controllers to contain the XLT protocol, without detracting from their own superior aspects. Zero3 will be happy to share this technology with our partners, for free. We can collect our revenue when the customer decides to sign on to the larger network, if the OEM wishes. There is no question there are other workable ways we can cooperate, also.

Zero3 Business Model

Zero3 and ACIWebs do not wish to become a monitoring company, a controls manufacturer, or a refrigeration service group. Our single goal is to function as a conduit for high speed access and a common communication platform to refrigeration sites around the country, and eventually around the world.

Our business model is simply to sell the XLT itself, and to provide the underlying Central server system for communications. We are willing, and actually eager, to work with others in building many value added applications on top of this platform.

When it comes to competing OEM’s using the XLT system, we fully intend to be aggressively neutral. This is the ONLY way we can provide full service to our core concepts.

XLT – How does it work?

XLT: The XLT talks to the Legacy System as if it were a human user, sitting next to the controller and constantly asking questions. It takes the data it acquires this way and translates it into a database, a completely common/neutral database that represents a proto-typical supermarket, not wedded to a particular controller. This database is then accessed from the Central Server via the Internet.

Central Server: The server waits for a user to request access to a particular site, then builds web screens to provide information about this site. These web screens are then passed to the user.

The User: Internet Explorer, Netscape, etc are used to access any store that’s on your “Allowed” list.

Neutrality: Zero3 is extremely Legacy Neutral, able to work with manufacturers of the Legacy equipment out there. Most have so far been supportive.

XLT Benefits

Random Access: We get direct small pieces of data from the site, without having to go through multiple screens to get it.

Commonality: All data accessed is the same, no matter whether the Legacy system is ComTrol, Danfoss, CPC, or Altech.

Allows for consistent, common and sophisticated algorithms with site data for detailed and productive analysis of failure indications, past records for new ideas, trends & properties for proactive trouble interception.

Upgrading: Allows for building a futuristic system based on older technology, providing modern advantages while legacy equipment is being replaced over a longer schedule with rational costing.

New Ideas: Using Random Access and Commonality, ideas such as Global Change of lighting schedules, Energy Optimization, etc. are only a fingertip away.

The future of such systems is only limited by imagination, yet using them will remain consistent so constant retraining, at tremendous cost, and with extremely highly variable results, is not required.

XLT Progress

Version 1: Initial prototype. UDP to web & flash. Rendered circuit status on floorplan. December 2006-January 2007.

Version 2: Flash & UDP for circuit floorplan, alarms, suction, condensors, HVAC. January 2007 - March 2007

Version 3: Flash & Server XML exchange. Rewrote all XLT interaction to use a caching service. Took advantage of improved speed to add weather, store schedules, Lights, Lighting schedule & HVAC schedule. Added two live stores with XLTs, connected via VPN to Blacksburg, in addition to the demonstration controllers in Blacksburg. Added user administration with 9 authorization levels and administration. Created web tools to administratively add stores & modify circuit & light layouts. March 2007 - August 2007

Version 4: Expanded existing services to allow write-back of change data: setpoints, analog offsets, overrides, schedules, holidays, relay overrides. All integrated with authorization-level permissions and site security. August 2007 - January 2008.

Future versions:

Version 5: Incorporate alarm receiving & distribution, graphing, expert system and real-time energy mapping. (in Development, May 2008)

Version 6: Incorporate dynamic query engine for ad-hoc queries, global changes, and additional management tools. (in Planning)

XLT Frequently Asked Questions

Q: “Isn’t Screen Scraping Obsolete?”

A: Yes it is, but it works just fine. So are the Legacy Control Systems that it’s used with, but they work just fine. The advances in supermarket control systems came long before the advances in communications. The funny thing about the word ‘Obsolete’ is it means there is something newer available, not necessarily something better.

Q: “What if Legacy Manufacturers change screen software?”

A: Just how many times has that happened in the last 10 years? And why would you allow them to change it if the equipment in place does a proper job. But just in case there is some good reason for such a change, the Screen Scraper can be updated just as easily, if not much more so, than the Screen software itself.

Q: “What if the Legacy Manufacturer changes the protocol?”

A: The same answer applies as in the prior question. The protocol may be added to, in which case we’ll add to our translator. But, changing their prior standard would be a very costly and foolish thing, since all their users would have to change to new communication software. Finally, if the remote lightning does strike, the XLT can be uploaded with a new translator in about 30 seconds per site.

XLT Frequently Asked Questions

Q: “What about interfacing to new Controller models?”

A: Again, with true neutrality, we can do a new translator for the new ‘Legacy’ equipment, usually before it ever really hits the market. It is entirely possible that future versions of controllers from some manufacturers will come with the XLT protocol built in, making them even easier to put on our network.

Q: “What about differences in operations of Legacy types?”

A: An example: What Com-Trol calls ‘Ambient Modified’ operation of Condensers, CPC calls ‘TD’ operation. But the setpoints and approaches are similar enough to make common data easy. (We called it ‘TD’). When there are real differences, the protocol and screens provide for either/or displays and data.

XLT Frequently Asked Questions

Q: “What’s needed to connect the XLT package?”

A: There are three possible methods: First, the package can go on the in-store private network. Then a VPN or bridge is installed at company headquarters. Second, a DSL line can usually be installed in the store. Third, we have a cellular ethernet modem available that avoids all wiring issues. One way or another, we can get you on the net. Short of that, installation requires sticking the XLT on the wall, and pushing an on-screen button to learn the site’s system, and doing a small sketch of the floor plan for that site (Optional).

Q: “What Legacy Systems does the XLT support?”

A: The ComTrol 5000/4000 series. The CPC RMCC. The Danfoss EIL. The Danfoss ZX/NC25, CPC Einstein, Altech’s XPert systems, a BacNet translator, and others are all in various states of progress and testing, as are the Scottish Honeywell Elm and Germanys Linde-Eckelman. Others will be added as business requires. It is entirely possible that future versions of controllers from some manufacturers will come with the XLT protocol built in, making them even easier to put on our network.

XLT Frequently Asked Questions

Q: “What’s securing my Corporate network if I allow you to pass through it to your equipment?”

A: The XLT goes on the in-store private network. Then a VPN or bridge is opened at company IT headquarters, pointing to the SERVER at ACIWebs in Blacksburg, VA, on the campus at Virginia Tech. In point of fact, this method is also the most secure. As we stated earlier, the XLT does NOT do it’s own web screens. It only provides raw data from the Legacy machines. So when a technician calls up Site123 to look at the Ice Cream case, he’s not actually talking to Site123; He’s talking to the SERVER at ACIWebs, which is building his requested web screens according to the data the SERVER gets from the Site123 XLT. The ONLY computer that’s allowed to talk to Site123’s XLT is the SERVER at ACIWebs itself, not the eventual client. The VPN will only allow incoming messages from that one IP address, and only to the specific port designated. Any request from any other address or port is rejected. The protocol flowing over this connection is very directed, and does not allow excursion into operating systems or redirection. The possibility of hacking a system like this is vanishingly small.

XLT Details

The following screens are more detailed and ‘how it works’ than the previous. If you don’t care much about how it works, stop here.

XLT Translation Techniques

There are three kinds of Legacy Communications today:Teletype: Like Danfoss ZX/NC25. Data scrolls down page. When the bottom is reached, the screen moves up a line. Any time new data is required, the entire screen is repainted. Slow!!.Terminal: Like Com-Trol 4000/5000, RMCC, EIL. Uses escape sequences to position the cursor on screen, then prints characters. Allows for painting the screen once, then repainting pertinent data. Faster, cleaner, & effective, but requires a terminal that with the escape sequences.Protocol: Like Danfoss AKC-55, CPC Einstein. Uses a coded sequence of questions/answers to gather data, requires specific algorithms to turn this data into screens. Protocols are not public, but aren’t state secrets, either. Fair use laws allow for reverse engineering.

Legality: Teletype & Terminal modes are known as ‘Screen Scraping’. There is NO legal barrier to these techniques. For protocols, once controller companies sell a device, they can’t block owners talking to it. They don’t have to help, but they can’t complain. It’s in the public domain, since protocols aren’t copyrightable. As always, though, cooperation is better than confrontation.

XLT Benefits, Continued

Random Access: Means we get direct small pieces of data from the site, without having to go through multiple screens to get it.

As an example, assume we received an alarm from Site DCA117 where third circuit, fifth probe, has a temperature above alarm setpoint. An operator deals with the alarm, decides software to use (30 secs) calls back store (1 minute), walks through 3-5 screens (1 minute), then studies circuit screens (1 minute), to determine if the case is slowly recovering from defrost or if there is real problem. Based on results, he may or may not call the store and/or it’s contractor. Result: 3 to 5 minutes, most of the process dependent on operator decisions and training.

With random access, when an alarm arrives, it contains protocol data to access the circuit in question, without going through setup screens. Before handing the alarm to an operator, the receiving computer goes directly to the site in question (10 milliseconds), asks for last defrost termination time (~60 msec), current value of probe (~60 msec), setpoint of the circuit (~60 msec), and probe trend (~60 msec, up/down). Using this data, the receiver may choose to check back 5 minutes later, before involving an operator. It may decide to pass the alarm to an operator immediately. It may decide to call this a false alarm, and just toss it into a recorded bucket. It’s called an Expert System, and it takes about 240 msec to make a decision based on rules established by the best service people around.

When and if the alarm is passed to an operator, the pertinent data is painted on his right hand screen as fast as the site data paints on his left (5 seconds), along with an ‘Action Plan’ to follow in resolving the problem.

XLT & OEM’s – How does it work?

The XLT Communicates with OEM’s through a web server at ACI Webs in Blacksburg, Va. Requests are made and responses are sent in XML form for allowed recipients. Below is an example of those communications.

Request:

<?xml version='1.0' encoding='UTF-8'?><XLT CHANNEL='GE0204'> <GET Request='31,1,201,0,3'/> <GET Request='31,1,105,0,3'/> <GET Request='3,1,1,0,2'/> <GET Request='3,1,9,0,3'/> <GET Request='3,1,111,0,3'/> <GET Request='3,1,112,0,3'/> <GET Request='3,1,113,0,3'/> <GET Request='3,1,13,0,3'/> <GET Request='3,1,202,0,3'/> <GET Request='3,1,7,1,32'/> <GET Request='3,1,7,1,36'/> <GET Request='3,1,7,1,2'/> <GET Request='3,1,7,1,3'/> <GET Request='3,1,7,2,2'/> <GET Request='3,1,7,2,3'/> <GET Request='3,1,7,3,2'/> <GET Request='3,1,7,3,3'/> <GET Request='3,1,214,1,3'/> <GET Request='3,1,214,2,3'/> <GET Request='3,1,214,3,3'/> <GET Request='3,1,214,4,3'/> <GET Request='3,1,214,5,3'/> <GET Request='3,1,214,6,3'/> <GET Request='3,1,211,0,3'/> <GET Request='3,1,212,0,3'/> <GET Request='3,1,213,0,3'/> <GET Request='3,1,216,0,3'/> <GET Request='3,1,217,0,3'/></XLT>

Response:

<?xml version='1.0' encoding='UTF-8'?><XLT Channel='GE0204'> <GET Response=“XLT-GE0204"/> <GET Response=“Com-Trol 6K"/> <GET Response="A01 14'MD FF"/> <GET Response=“Dripdown"/> <GET Response="Hot Gas"/> <GET Response="Disc Air"/> <GET Response="Solenoid"/> <GET Response=" -2.9"/> <GET Response=" -8.0"/> <GET Response=“ 5.0"/> <GET Response=“-20.0"/> <GET Response="MDFF 1-1"/> <GET Response=" -4.3"/> <GET Response=“ -6.2"/> <GET Response=“ 1.7"/> <GET Response="NO_EXIST"/> <GET Response="NO_EXIST"/> <GET Response=" 8:00"/> <GET Response="16:00"/> <GET Response="None"/> <GET Response="None"/> <GET Response="None"/> <GET Response="None"/> <GET Response=" 60.0"/> <GET Response=" 0:20"/> <GET Response=" 0:05"/> <GET Response=" 0:00"/> <GET Response=" 0:00"/></XLT>

XLT & OEM’s – How does it work?

At the server in Blacksburg, the web server that provides data service has several functional elements:

An XML command to the server “Opens” the site. This open loads the site data-base into memory, and starts reading all transient data in bulk from the site XLT. It can cover all data in ~8-10 seconds.

The server itself provides answers to XML requests. It is important to note that there is no required fixed order or pattern to these requests, they are completely free form inside the bounds of XML structure and the XLT protocol. The server supplies data directly from the site for run-time info, and from a local data-base for setpoints & configuration info.

A companion program is constantly checking for changes to data-bases in the sites (~5 min intervals). Any time a change is found, the site data-base is reloaded to the server (~45 seconds).

The only IP address the VPN at the Chain’s IT system ever sees or allows is the server in Blacksburg, creating a very high security level.

XLT & OEM’s – How does it work?

Q: “What else can the XLT do I’m not doing now?”

A: Below is a possible approach to Energy Monitoring in Real Time.

Extras: The XLT also interfaces to monitoring devices such as Veris Systems Modbus CT energy monitors, in parallel with the relevant rack systems, to provide a single view from setpoints to results, to better able true energy reduction.

XLT & OEM’s – How does it work?

Q: “Is there more?”

A: The XLT can provide structured answers to queries about your entire chain, in minutes. For instance, if you would like to know which stores, if any, have case probes in override, simply select the info you want on the Chain Query page, and hit submit. Within 5-10 minutes, you will receive an e-mail with a readable report on the results.

Q: “Any more?”

A: The XLT can provide structured commands to all your stores as well. When the original legacy systems were installed, no-one thought being rigid about task names was critical. However, today, if we wish to alter the schedule for all parking lot lights, we need an operator to look at each task in each store to resolve issues such as the difference between “Parking Lot” and “Outside Lights”. With the XLT, during set-up, the installer optionally adds a number identifier to each task. So when we go out to add a half hour to each parking lot task, the system searches for #900 tasks, not by name.

Q: “And?”

A: The XLT can do much more than we have already thought of. Let us know what you want, and we can probably do it.

XLT and Expert Systems

Expert Systems: One of the paths of the future is an Expert System approach to dealing with site alarm monitoring & maintenance. In the current and legacy RMCS systems, about 60% of alarms turn out to be false, or repetitive, or unimportant. But training humans to deal with this is not only problematic, it is expensive. The Expert System will receive an alarm with a computer, then do a healthy amount of decision making prior to calling in the efforts of a human operator. This decision process will be based on the collective wisdom of a reasonable group of highly experienced refrigeration/HVAC techs, distilled into code, or ‘Rules’. To make this practical, there must be real-time communication with the site allowing small random access questions at high speed.

As an example, assume we received an alarm from Site DCA117 where the third circuit, fifth probe, has a temperature above alarm setpoint. An operator deals with the alarm, decides software to use (30 secs) calls back store (1 minute), walks through 3-5 screens (1 minute), then studies circuit screens (1 minute), to determine if the case is slowly recovering from defrost or if there is a real problem. Based on results, he may or may not call the store and/or it’s contractor. Result: 3 to 5 minutes, most of the process dependent on operator decisions and training, and a healthy part of this time unproductive work in the first place.

With random access, when an alarm arrives, it contains protocol data to directly access the circuit in question. Before handing the alarm to an operator, the receiving computer connects directly to the site, asks for last defrost termination time, current value of probe, setpoint of the circuit, and probe trend (~3 seconds). Using this data, the receiver may choose to check back over 15 minutes, before involving an operator. It may decide to pass the alarm to an operator immediately. It may decide to call this a false alarm, and just toss it into a recorded bucket. It takes about 100 msec to make a decision based on established rules. When and if the alarm is passed to an operator, the pertinent data is painted on his right hand screen as fast as the alarm data paints on his left, along with an ‘Action Plan’ to follow in resolving the problem.

The key to this operation is the random access and commonality discussed above. If an Operator must dial up, then log-in, main menu, secondary menus, etc, before getting to the heart of the matter, efforts bog down quickly. Also, if there is a different series of operations for Danfoss or CPC or ComTrol, the rules become a crazy quilt instantly. In the scenario above. You might say, “It’s only looking at the store once a minute, so that’s not difficult!’. Remember, however, that same system might be monitoring 5,000 sites, and these questions need to be answered in milliseconds, so we can get on to the next site doing the same thing. Further, the system can look at the past, see this has happened every third day for three weeks, and send a notice to ‘Site Efficiency Operations’ saying “You should look at this”.