, , ,

My First IIoT Application: Part II

My First IIoT Application: Part II

Written by Ron Batra

Following up to my previous post, sharing some more details on our first foray into IIoT. I’d like to thank the community for great comments and feedback. 
Year: 1997 !!  Almost 18 years ago.  

Team Size2 Developers, my good friend and colleague Terry and Yours Truly.  There was part-time involvement from 2 Business Analysts with deep Manufacturing domain expertise who helped sharpen business requirements and 2 Machine Operators who agreed to be test pilots. We “Project-Managed” our-self, and “Program Managed” our-self and pretty much ran a very lean operation. 

Machines: We had a total of just over 200 machines across different facilities, and we decided to start with a pilot of 6 machines (each had a unique controller type) to which we had to communicate.

Time Period: Less than 6 weeks for the first pilot.  The Data Model and code was very extensible and we designed it such that for every new machine, there were no code-rewrites, just data-entry via a few forms that we made for the manufacturing planning leadership.  We had backend access if needed, of course.

Platform and Technology: We had a few choices to make.  In 1997, we were not very sure of Windows Application and Web Server stability.  NetScape Internet Information Server was available, but it appeared most of the business logic would be heavy CGI scripts and/or we were not sure of the long-term stability.
Our toolkits of which we could choose from:
-Databases: Oracle, DB2/MVS, some MS-SQL Server.
-Programming Languages.: C, C++. PL/SQL, VisualBasic, some shell scripting, some Java, HTML, Javascript.
-Operating System: We had a choice between AIX, Solaris, and HP-UX.
-Application Server Platforms: NetScape, Oracle, Sun (iPlanet I think), MS-IIS (was used sparingly)

How we chose our Platform
-There was not much I could not do in Oracle and PL/SQL and was pretty strong in C as well. I was also pretty good at VisualBasic, and in fact we had some true Client-Server programs written on laptops in VB, that I used to walk around the shop-floor communicating directly with the machines (Hint: Laptops used to have Serial Ports back then). 

My colleague Terry could do some insane magic in C and was a guru in communications programming as well.

Platform X Architecture

Looking at all factors for the pilot, we went with Oracle Application Server Version 2.0and most of the front-end, business logic and database logic were in PL/SQL.  We were learning Java, but were not that fluent in 1997 and didn’t have a budget to hire a Java programmer. In addition, Windows based platforms were not very popular in the late 90’s for server-side computing.  

We generated HTML and Javascript using libraries Oracle had provided (htp and htf packages and procedures basically). We had basic wireframes, and this was not an eCommerce application so it was relatively simple compared to some of the applications today.  Terry did his magic in Ansi C and after the “Submit” button was processed, some routines were invoked and the communications between Ethernet and Serial was initiated, completing the “IT-OT” bridge.

Our lessons learned:

  1. The Lightbulb moment: We had a lot of knowledge about the machines and I had written a Client-Server style program in Visual Basic that used to run on a laptop.  We used to take the laptop and attach a Serial Cable from the laptop to the machines.  One day, one of the manufacturing leaders mentioned casually, “Since we cannot have so many of you walking around with laptops, can you do what you do on a server somewhere”.  That started us down the path of a Web Application, and we found a way to get an Edge Device that could do Serial Communications with Ethernet/TCP/IP as an input.   Once we finalized that high-level architecture, then it was just a matter of filling in the gaps.  We had already learnt the travails of Client-Server and upgrade, so we made sure the application that would run in a browser
  2. The “Aha” moment: When we went live, we were proud of the technical accomplishments that were able to connect the machines to be operated from a standard browser. However, from the business perspective, that was not what they saw as “Epic”. What they loved the most was that they could work the UI from a browser. The comment was “This is just like NetScape we used at home on the Internet”.
  3. Communications: We were communicating a set of admittedly discrete data to the Machine and getting back some basic acknowledgments about the status of the program.  The machines were not mobile and we had LAN and WANs that were robust.  So really we had to bridge TCP/IP to Serial (RS232) communications.
  4. The Big Data and Analytics Question: Never really occurred for us back then, since there was a separate set of programs designed to track analytics that fed to leadership KPI’s. As part of this work effort, at least initially we were not collecting every “bit and byte breadcrumb trail” of the machines as it machined the parts. The controllers depicted in Part 1 of this write up, actually used to track data in real-time in x, y, z coordinated plus cycle-time, tool changes, number of operations performed etc.  But we saw not a reason to re-capture that data and merge it with other data-stores.
  5. Simplicity Won:  We didn’t let ourselves be enamored of technology and did what we could do best. I still remember the data-model and the E-R diagrams we created while modeling the relationships and the business rules – KISS won again (it always seem to win). We had no API’s (Public or Private) – this was an internal platform, and we kept it lean and light.
  6. Agility, Politics, and Bureaucracy (lack of):  We were part of Business IT, and did not have to wait for an IT-based multi-year IT roadmap (Grin!!),  (IT that the business used to fund !!) and business case rationalization for the pilot. We used the software we had in house, 4-6 weeks of development time was quite acceptable, and for 6 machines, the total cost of edge devices cost was less than $2000 total. This was not even a rounding error when you look at the bigger picture !!

Today’s context and impression of IIoT is different in that the perception that sensors, edge devices etc. will be generating copious quantities of different types of data real-time and what does one do with that data. As I mentioned, this was our first foray into IIoT, and we didn’t know we were doing this in 1997!  

This was meant to be largely inspirational and I’m sharing our trip down memory lane. I appreciate the feedback including some who took the purist’s view of IIoT.  All good. !! 

If you lose the click to my first post, here’s a graphic I published in Part I.

 

 Now to get to today’s generation of IoT and IIoT – In my next posting, I’ll probably talk about a few items of interest in today’s computing landscape including the definition of edges, sensors and modern communication and messaging protocols that are expected to come in play.

Ron Batra is a Technology Thought Leader | Advisor | Consultant | Cloud, Internet of Things and Edge Computing

Connect with Ron on LinkedIn and Twitter:

At Nelson Hilliard we specialise in cloud technologies, sourcing the top 20% of cloud professionals inspired to work for you through our specialised marketing and profiling. If you are interested in having a quick talk to me regarding your employment needs please feel free to reach out.

You can also check my availability and book your 15 minute discovery call here.

Brad Nelson