6

To begin, I have been assigned the task of automating a significantly outdated manufacturing tool. The tool and it's API and software are virtually unsupported now. I have a collection of documents describing what amounts to an operator's manual of the software, and an introductory level of the API. I have gotten this far by compiling this information, along with the .h files (most of which were given no explanation by the documentation).

I have reached a point however, where the API has no (known) way to measure or track the progress of an integral action. I have been able to characterize the related functions in the API fairly well and under ideal circumstances, could probably produce the desired actions, however I believe this leaves a huge vulnerability to errors or nearly anything that isn't exactly what is planned for. This is what I seek to improve.

More specifically, the loading action of the tool is reliable under certain conditions, but I have no way of discerning, programmatically, when the action completes or it's result. By overestimating the time, I can make the process successful most of the time, but I have no way of knowing whether or not the action failed (e.g. when the input runs out).

My question is how to increase the robustness of my program, what principles to implement, or what resources might be able to provide some insight on this issue.

Note: I'm more than happy to provide more information if needed/helpful.

rtmh
  • 643
  • 5
  • 8
  • 1
    your [Anti-Corruption layer](http://programmers.stackexchange.com/q/184464/31260) seems to be leaking... – gnat Aug 03 '16 at 20:59

1 Answers1

13

Some things you can do:

  • Implement Façades/wrappers to make internal calls in the order the API expects them.
  • Add a lot of error/exception handling to wrappers
  • Sanitize input data as much as possible
  • Add logging capabilities to the wrappers
  • Create a testing laboratory when you do thourough, certifiable test by analysing the inputs and results.
  • Have some engineer do reverse engineering of the tool to get knowledge of the inner workings, signals, etc.

All that are just workarounds and scafolding, the real work is a work of forensics, testing in controlled environtments.

Lastly:

  • Can you rewrite the API?
  • Is the manufacturer of the tool no longer in business?
  • Do they offer a newer, supported version of the tool and its API?
  • Does a third party other that the original manufacturer give support?

Sinces this API controls a manufacturing tool, errors will cause loss of material and/or accidents to people working with said tool when testing new functionality programmed to that API.

Sometimes a company has to move on to new technologies.

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154