Many Questions, Too Few Brain Cells Remaining

[Heterodoxy]

Time to come clean, my day job would be one of a ambitious, self-motivated, and maybe slightly over confident sparky, with a thirst for knowledge. Recently a friend brought me aboard his pre-existing small business to do some trouble-shooting & programming on small control systems using AB products. (Which I’m primarily familiar with) Now, this thing has expanded beyond our expectations. (Mine anyway, with much large systems now!) Anyway, We had a client come to us with a proposal to develop a control system using their proprietary algorithms. But with a hitch! They were very insistent that the code protects these algorithms. What they suggested was a deviation of what their competitor does. Which is, that if an end user accesses restricted sections of the code that could damage the machine or divulged the particular algorithms, that the code would store a violation flag (which their service tech could detect) and that the PV would make them (the end-user) know that we are aware of the intrusion…. So, never doing anything of this nature I did the usual. Which was to come to this website first and perform the customary searches, security, password, trap-door, ect… It didn’t take much reading to learn that this is a heated subject !!! But what you have to realize is that, this isn’t a time bomb or anything to persuaded payment. It’s main purpose is to deter end-user’s from performing the above mentionable’s. And to make the end-user aware that they have terminated the warranty. Now to all of the nay-sayer’s ---- these conditions will be upfront to the customer, (contractual) and there will be no process stoppage (to defer any legal actions)
Now with the confessions and the explanations out of the way. Onto the question, finally – how do I accomplish this task? Or is it even possible? Another thing is that this client sets themself's apart from their competitors by letting the customer (End-User) own the code. Meaning that the customer can make changes to any part of the code not deemed proprietary. Now I might be complete wrong, but as I explained to the client. It wouldn’t take much to defeat any monitoring, because let’s say that they get curious and make changes that they deem necessary. And afterwards the process crashes. Then it would just be a matter of clearing the memory and reloading the original program onto the processor and saying: I don’t know what happened, but I’m not paying for it! The clients response to this was “what if, we provided a copy of the original program onto a eeprom and flash any changes made onto the chip” And as I explained again, it would just be a matter of uploading a copy of the original program onto their hard drive before any changes were made and downloading it back if anything went wrong! So I can’t see any way around this, or is there something that I’m missing? I read in one post something about password protecting certain sections of code, ladders, subroutines, something like that? This seems interesting, how is that preformed?

Many Thanks
Heterodoxy

 

[LadderLogic]

Do I understand you correctly that the code, including the proprietary part, must be implemented in Allen-Bradley PLC?

 

[Heterodoxy]

Yes, unless there is another alternative that I’m not aware of ? We’re looking at using a 5/03, 5/04, or 5/05 depending on what the customer needs are.

 

[Tom Jenkins]

You could use a separate PLC with all of the proprietary code.

The "public" non-proprietary logic would be in the SLC. You could use another SLC (or maybe even a MicroLogix depending on memory requirements) with the proprietary portion of the program logic. This second PLC would be password protected, and you could put it in Run mode and keep the key. A small communications link, DH 485 or Df1 or whatever, could join the two. The "proprietary" PLC would read data from and write data to pre-assigned registers in the "public" PLC.

A similar concept, although it might be harder to implement, is to use a BASIC co-processor in the SLC rack and put all of the proprietary code in it. I don't know enough about the A-B BASIC modules to say for sure, but I'd be real surprised if they didn't have some kind of program protection avaialable.

 

[Heterodoxy]

Thanks Tom,
That is a clever alternative that I hadn’t thought of! Personally I fell that the protection over the cost would justify the additional processor. It would just be a matter of convincing the client that this would be the best possible solution. But my major concern would be, just how secure is the password protection scheme in the SLC ? I’ve read several posts from different individuals that state their ability to bypass such security?

 

[ArikBY]

If you concern about the password maybe consider to use OMRON.
In OMRON if you try to pass the password more then 5 times the PLC is locked.
The only way to enter the logic is by erase the existing logic and download agine.
You need to be PRO to cross the password.
I guess it would be cheaper then AB.

 

[mday]

The SLC can be hacked, just like anything else can using communication sniffers. I think the back door for SLCs has been disabled in RSLogix 500 (been told that anyway, have not tried myself). How about using two SLC 5/04s tied together via DH+. On the 504 that is running your secure code disable channel 0 so that no one can sniff the serial comms for the password, your only entrance into that processor would be through DH+ and your password. Just a thought, but costs $$$ more.

 

[Heterodoxy]

Thanks ArikBY,

For the recommendation, but I’d prefer to stick with AB. Because this is what I’m most familiar with!

 

[Pierre]

What is the nature of those algorithms?

Of course they would not deal with normal complex logic, they must be dealing in an area where your client has a particular expertise.

Something like a deterministic K factor related to an heat treatment process, including multiple zones each having a relation to the next one.

Just tell us a tiny little more and we can give you a few more hints on how to do this.

For instance, "intelligent" modules...

 

[Alan Case]

I agree with Tom, but I would use a micrologix 1500 for the proprietary code. SLCs are too easy to hack, ML1500s are a lot harder if not impossible. Use DH485 to message the info required between the processors. You may even find a performance boost as I found the ML1500 does process some info very fast and you have unloaded the maths from the SLC. Regards Alan

 

[Heterodoxy]

No Pierre,

Nothing that technical, it’s primarily storage for command codes to initiate full control to the Skynet System and to relinquish Norad missile controls.

….NO….NO….NO… I’m sorry Pierre, I couldn’t resist!

I see this as a collection place of all vital inputs, from there process control decisions are made, and the use of 1 PID loop out of several loops decided upon. I know kinda of a vague description, but basically they want to protect their process control decision-making section! And being on the same end, I can’t blame them for wanting to protect their interest. Nobody wants to be cut out of the loop!

Thanks, to all who responded thus far.
Hope everyone had a great holiday and would like to wish all of you a prosperous New Year.

Heterodoxy

 

[JesperMP]

To detect that the customer has loaded the program:
Evaluate the system bit S:5/8 "Memory Module loaded on boot". If ON: capture the CPU time S:40-41-42 and date S:37-38-39 and then reset S:5/8.
You can then use this captured time, in case you have to prove that the customer has loaded the program.

To protect the proprietary code from being "disassembled":
Write the code in a "garbled" manner with some dynamic JMP commands.
Do not provide any comments apart from "Propretary code. Do not alter ! "
It will not be impossible to figure out, but will deter the casual change of the sensitive code.

 

[Peter Nachtwey]

Hmmm, how much is this secret worth?

I see this as a collection place of all vital inputs, from there process control decisions are made, and the use of 1 PID loop out of several loops decided upon.

I bet there are many good control engineers that can just look at the process and they would know what the 'secret' is. Is it worth all the effort? If so then I agree with Pierre. Any sophisticated algorithm would be a pain the rear to implement in a PLC. Sometimes secrets are to hide flaws.