How a processor end-of-life announcement led to the development of JANOS, the custom operating system that powers JNIOR and preserves continuity across hardware generations.
— — — — — — —
Every embedded device has an Operating System (OS). But not all operating systems are of the same level of sophistication. There came a point when JNIOR needed to take things to another level and in the process it received a very unique OS upgrade.
A device design might start out with the selection of a hardware platform followed by a review of the operating firmware available for that. Product development then entails the selection of an I/O set; The shaping of the hardware into a distinctive enclosure; And, the building of a user experience through programming built on top of the base firmware.
This is how JNIOR started life.
An alternative approach, prevalent today, would revolve around the selection of a preferred operating system followed then by the review of the available hardware platforms that can support it. Either way the process is not simple.
It is additionally important to consider details of the Integrated Development Environment (IDE) to support the effort. Much depends on the programming language(s) of choice and the expertise of the developers. And, the selection of a product enclosure and ultimate product presentation, not to mention manufacturability, do complicate matters more than you would think.
JNIOR had to overcome these obstacles more than once.
In the late 1990s Sun Microsystems had been pushing the deployment of embedded Java. Semiconductor manufacturers were supplying processors with a built-in Java Virtual Machine (JVM) for that purpose. This was the proper selection for any device being designed to provide remote I/O accessible over the local network. That was also a perfect choice for early JNIOR.
JNIOR is after all a device devised as a tool for controls engineers needing a cost-effective way to augment largescale systems, those involving high level computer software and intensive low-level PLC controls. Often it would be necessary to drop an I/O point here or there without the cost and risk of disturbing the PLCs. JNIOR is an attractive option for temporary diagnostics or in testing the feasibility of I/O changes in those sensitive production systems. It fit that role nicely.
Designed to be a reliable network-connected controller, JNIOR monitors inputs, controls outputs, and provides a simple way to connect systems. It does that job well and so quickly found a niche in industrial applications and later in the deployment of digital cinema.
For several years life was good.
Customers deployed JNIOR in ways that we had anticipated, and in a few ways that we had not. As often happens with successful products, users discovered capabilities that were not part of the original plan. One installation would use a feature in a creative way, another would ask for something new, and before long the platform was growing beyond its original mission.
As networking became more important, customers wanted more intelligence closer to the equipment being monitored and controlled. They wanted local automation, local decision making, local communications, and local integration with other systems. They wanted a controller that could do more than simply move inputs and outputs across a network. We didn’t call it ‘Edge Computing’ back then. We just called it “solving customer problems”.
JNIOR evolved accordingly.
Applications became even more sophisticated. Networking demands increased. Security was becoming important. JNIOR was being asked to solve problems that simply hadn’t existed when the product was originally conceived. And that began to challenge the platform.
The pressure to perform tasks outside of the original product concept drives companies to rollout newer, more expensive models of devices; This presents customers with an ongoing cost in upgrades; And, perhaps it unnecessarily stresses landfills and recycling facilities. Instead, we kept finding ways to encourage the JNIOR platform to step up and handle the growing need. That was becoming difficult.
And soon JNIOR got to be known as a “workhorse”.
JNIOR was successful. Thousands of units were deployed globally. Customers were building systems and businesses around it. There was momentum and we had never expected the semiconductor manufacturer to then announce the processor’s end-of-life.
Continuity is important. Stability is important. You have to be able to plan for the future. If you make a commitment to a product, you are hoping that it would be available for the foreseeable future and not leave you back at the drawing board, at least not too soon. For JNIOR it was too soon. The question was how to provide that continuity for our committed customers regardless of the turn of events?
For most companies the response to this would be a new platform. That would mean new basic operating firmware and new product software development. That ultimately leads to a new customer experience. Good or bad, it means a break in continuity. Pricing changes. Documentation changes. Procedures change. And, as always, cost goes up.
The interruption inflicts a pain that propagates.
Clearly, we would have to choose a new processor. It would be possible to retain the form and continue to use the same enclosure. Physically the product would not change in appearance. But what about the details? It would still be a new platform and with that the customer experience would have to change.
The operating system in the Series 3 JNIOR was not available to be ported to a new platform. We had pushed that to a limit as it was. That was not a choice.
Commercial operating systems offered advantages but introduced dependencies. Real-time operating systems solved some problems while creating others. Linux was powerful but brought complexity that did not align particularly well with our goals. More importantly, every existing solution wanted JNIOR to adapt to its architecture. We wanted the architecture to adapt to JNIOR.
In order to move forward without disrupting the JNIOR ecosystem, we needed to develop our own operating system.
The objective was not to create an OS for the sake of creating an OS.
The objective was to preserve the characteristics that made JNIOR successful while allowing the platform to evolve in the best possible way.
And so, JNIOR would get its very own operating system, governed by perhaps the most outlandish concept. It would not be dependent on any third-party code whatsoever. If it were to be deficient, there is to be nowhere for us to point fingers. There would be no bug, or feature request, that we could not promptly address.
The term Operating System has become diluted over the years. Today almost anything that boots a processor is liable to be called an operating system. A Raspberry Pi image bundled with a custom application may be marketed as an OS. A simple scheduler with a few timers and drivers is often called a Real-Time Operating System (RTOS). In embedded systems the definition can become surprisingly loose.
That was not what I had in mind.
If JNIOR was going to preserve continuity while also providing a foundation for future growth, it needed more than a scheduler and a collection of device drivers. It needed to become a complete platform. Applications would need to be isolated from hardware details. Resources would need to be managed. Communications services, storage management, security, diagnostics, process scheduling, and application support would all have to work together in a predictable and reliable way.
In practical terms, this meant that writing an OS was not the development of a single piece of software. It was the development of an entire software ecosystem.
When I suggested writing our own operating system, there was understandable skepticism. I had joined INTEG in a hardware development role and was surrounded by talented software engineers dedicated to other projects. From their perspective, my proposal may have seemed unexpected, even rediculous. The task appeared enormous. Would we have the resources for that?
What they did not necessarily know was that hardware and software had never been separate disciplines throughout my career. The hardware existed to support the software. The software existed to take advantage of the hardware. The product was the combination of the two. I had developed operating systems in support of hardware before, and I understood both the challenge and the commitment that effort would require.
I was adamant that we move forward in this direction. Not because writing an operating system sounded interesting, but because it was the only approach that fully solved the problem. JNIOR needed continuity. It needed longevity. It needed independence from the decisions, priorities, and limitations of third parties. Most importantly, it needed a foundation that could evolve as hardware evolved, and as JNIOR evolved.
If this OS succeeded, future hardware transitions would become far less disruptive. The operating system would belong to JNIOR. The architecture would belong to JNIOR. The future would belong to JNIOR.
You might not expect that one of the most difficult tasks in getting a product developed is in designing the enclosure. Well similarly there is an initial challenge in operating system development, actually naming it. Much as you need a target container for PCBs, displays, switches and connectors, you need a name for your IDE coding project, your source control repository (SVN), and for that in the issue tracking system (Redmine). And, given the operating system’s role in the future of the product, it needed a personality.
Initially the name emerged from an acronym:
JNIOR Automation Network Operating System (JANOS).
While that acronym worked, another connection soon became apparent and that sealed the deal.
Janus is the ancient Roman god of gates, doorways, transitions, arrivals, and departures. That name absolutely seemed appropriate (with a slight play on spelling) for an operating system whose primary purpose involved communication and the movement of information. A platform focused on inputs and outputs, messages, connections, and control could hardly ask for a more fitting namesake.
The acronym stuck. The initial obstacle was overcome.
From the beginning, JANOS was never intended to be merely a replacement for the firmware that had powered Series 3. The goal was continuity and we also wanted flexibility and opportunity.
That meant more than supporting inputs, outputs, networking, and storage. JNIOR had been built around Java from the beginning. Customers had invested years developing applications and workflows around that environment. If the new platform could not execute those applications, then the continuity would not be achieved.
As a result, the scope of the project was clear from the outset. A new operating system would be required. A new Java Virtual Machine would be required. Communications services, security, storage management, diagnostics, and development tools would all need to be recreated on a new hardware platform and at a new level.
The objective was ambitious but straightforward: a Series 3 user should be able to move to the new platform without feeling as though they were adopting a completely different product. That requirement influenced every design decision.
The operating system could not simply manage hardware resources. It had to provide a stable platform upon which JNIOR could continue to evolve. The JVM could not merely execute bytecode. It needed to preserve the application environment and runtime class libraries that customers had come to depend upon.
Viewed individually, each of these components represented a substantial development effort. Together they formed the foundation of the next generation of JNIOR.
By mid-2013 the new hardware platform had become reality. Over the following year JANOS matured rapidly as applications were ported and capabilities expanded. The true milestone was not that a new operating system had been written. The milestone was that existing JNIOR applications could run successfully on an entirely new platform.
Only then could Series 4 legitimately take the torch from Series 3 as it did.
Looking back, JANOS achieved exactly what it was intended to achieve.
The objective was never to create an operating system for its own sake. The objective was to preserve JNIOR while allowing it to evolve. Customers needed continuity. They needed confidence that their investment in applications, procedures, and product knowledge would remain valuable despite a major hardware transition.
The result exceeded our expectations.
Series 4 delivered dramatically greater performance while preserving the concepts and capabilities that users already understood. Existing applications could move forward. New applications could take advantage of a far more capable platform. JNIOR remained recognizably JNIOR.
Perhaps the greatest validation of the decision is that JANOS continues to evolve more than a decade later. Development today is not focused on making the operating system functional. That goal was achieved years ago. Instead, development is focused on extending capabilities, improving diagnostics, enhancing security, and creating new ways for JNIORs to work together and with the rest of the world.
Recent additions have included features that allow peer JNIORs to share information and coordinate activity across a network with very little application complexity. Security continues to evolve as industry expectations change. New communications capabilities have been added whenever they provided value to customers. Because JANOS belongs to JNIOR, there is no external roadmap dictating what can or cannot be done.
The decision to develop JANOS was originally driven by a processor end-of-life announcement. Ironically, the greatest benefit may have been the independence that followed. Hardware platforms will continue to evolve. Technology will continue to change. Yet the operating system, architecture, and future direction of JNIOR remain under our control.
Today JNIOR controllers are deployed throughout the world in industrial automation, digital cinema, energy management, environmental monitoring, and countless other applications. The Series 4 platform has become the workhorse that Series 3 once was. And when the next major hardware transition becomes necessary, JNIOR will approach that challenge from a position of strength.
That may ultimately be the most important result of all.