You shortlist 2 integrators to help you with your Ignition-based SCADA project. They both visit your site, look around, and ask questions about your current situation.

Integrator A sits down at your table, takes out a tablet with a fresh Word document open, gives you a big smile, and asks: “alright, what do you want us to build?”.

Integrator B sits down at your table, asks further questions about architecture and standardisation of data structure and about small problems you have in the daily operations. After listening to you, the integrator says: 

“Alright, I hear you. You want to achieve X, and you want to do it within a reasonable budget and, ideally, a short timeframe. Here’s how we’ve done that in a similar company, starting with the architecture that fits your ecosystem. Yours has its own unique characteristics, but we have a framework to navigate them, best practices to recommend from experience, and pre-made, but customisable, solutions to plug and play for a smoother implementation. Let’s connect some things and build you a dashboard right now to show you what we mean.”

If Integrator B is your cup of tea, please read on. 

What is the SCADA Project Framework? 

It is an end-to-end framework for a reliable and successful Ignition-based SCADA project—standardised plug-and-play tools and the plan to implement them.

Our claim is that you bring an integrator on board and expect them to have a plan about how to identify what needs to be done, prioritise tasks, know how to get it done, and make sure everyone stays informed and engaged along the way. 

To ensure that happens, we created the framework—and frankly, it’s as much for us as it is for you. After 6+ years of Ignition projects, we wanted to work faster by not starting from scratch every time. Now that we have the structural template for the most common solutions, we deliver faster without even sacrificing customisation.  

What are these plug-and-play tools we’re talking about?

Good question. Ok, here’s the thing: even though projects are different, they share similar elements. You’re asking for a SCADA because you want certain functionalities, and you’re not the only one who wants them. Therefore, given the frequency with which we had to build similar solutions for clients, we created the “Enuda way” of building the front-end and back-end. 

A caveat: the Enuda way is not the only way. If you have nothing (no standardisation of the data structures, no connection between machines/devices/processes, no infrastructure for a seamless data flow, no uniform design for the HMIs etc), we have a solid starting point with our templates. However, if you already have (some of) these elements, along with specific requirements for your solution, we will build it for you as you wish. We’ve done both several times. 

Some elements include:

• Trend Tool
• Tag Historian
• Alarming 
• Faceplates
• Navigation Menu
• Symbols & States

(Here’s a demo if want to see what the HMI elements look like)

But that’s just the tip of the iceberg.

Here are the building blocks that most SCADA projects share and that we can put together for you: 

Now, we left some clues about a new concept we’re introducing.

We mentioned that the framework offers “a set of templates put in a single source of truth for you to take advantage of standardisation and reusability”. In the above picture, you noticed “the template”, which is a catalog that answers questions about your SCADA.  

It’s time we clarified what the template is. 

The Template – what is that? 

There are two things you need to know about the template.

1. We already have templates for some standard solutions

Let’s use an analogy: imagine you want to buy a house. You have two options: you either start from scratch or you choose and customise some standard options that the house-building company offers you. The first option is valid, but expensive and time-consuming. The second one has the company saying “well, we have these 7 types of houses, these standard building blocks that you can choose from and customise depending on your budget and needs”.

We use the same logic when it comes to building SCADA solutions: we have something on the shelf for faster implementation. And we developed the tools by asking ourselves “what happens in almost all our projects?”, so it’s also a set of steps that guide the project. In essence, we don’t start from scratch.

2. We have a templating mindset

The solutions we build for you will become standard templates for your company. In one single source of truth – a catalog that is unique to you – you will find information about how your SCADA solution was built so you can take advantage of reusability. Moreover, training people will be easier because you can answer the question “this is how we do things”. 

What we do 



1. Proof of concept

A digital transformation project rocks the boat. It’s the bridge between “this is how we’ve always done it” and “we’re now working smarter”, and crossing that bridge is no breeze. Therefore, in the beginning, we suggest working under the radar for a while. 

In practical terms, that looks like identifying a small problem to solve to show value to the stakeholders (senior executives, operators etc). With Ignition in trial mode, we connect some things to get data, and build a working front-end that turns it into information for data-driven decisions. 

Please, don’t underestimate the power of starting small. Even in this phase, large manufacturing companies tend to go over the top, making the PoC much more complicated and abstract than it needs to be. 

We ask two questions: 

1. What is the purpose of the PoC – what are we aiming to prove? 
2. What is the minimum needed to achieve that purpose? 

And hey, we get it – you might need a larger PoC to convince the stakeholders of the value of your initiative. That’s ok, but still: start as small as possible, then extend the project. Get things connected, get data flowing, and then we can have fun with analysis. 

2. Access to data in one place

Just like we said above: the first step before having fun with all sorts of functionalities is to get things connected to the Ignition platform and have data flowing seamlessly. However, when you deal with data from different sources with different tag structures, you need standardisation to “clean it up”, to turn a mess into well-organised data. 

This is where the Unified Namespace comes in, along with the proper architecture that fits your existing ecosystem and allows for flexibility and scalability. We follow best practices and international standards like ISA-95. 

Once you have access to data, the fun begins because you have something to pull from and build the functionalities you want. 



3a. SCADA

SCADA is an acronym for “Supervision, Control, And Data Acquisition”. 

In a nutshell, you’re probably looking for: 

Supervision = you supervise/overview your processes and equipment. 

• overview process values,
• monitor alarms,
• follow the production in real time,

Control = you can interact with the process.

• by changing settings,
• start and stop processes.

Note: Supervision is information flowing from the process to you and Control is the other way. This is data flowing bi-directionally. 

Data Acquisition = collect data. 

• get real-time information about the processes – for example, set KPIs and stay informed about them.
• historical data for data analysis.
• all data is available to everybody at the same time in a unified format and contextualised.

3b. Manufacturing Execution System

You may be wondering why we’re talking about MES in a “SCADA Project Framework” article.

Well, while SCADA is pretty straightforward and we can all agree on a standard set of functionalities it provides, MES is many things. You’ll have a hard time finding 10 engineers who agree on exactly what MES is because it can look different depending on your needs. In fact, we’ve identified at least 29 business functionalities that sit under the MES umbrella.

However, in our experience, most people use the two abstract concepts interchangeably—and understandably so, nobody really cares about the concepts, they care about getting the data flowing and then using it to solve problems. They just create the user stories and ask for that functionality – whatever abbreviation we use to describe it is insignificant to them. To us as integrators, though, it’s a bit more important, but that’s on us. 

Among the requested functionalities, five make an appearance most often: 

1. Real-time data collection and acquisition = make data available, centrally in a uniform manner
2. Performance analysis = OEE (at different levels) 
3. Work order management = WO is the order to manufacture NN items. Includes BoM, BoP, date, detailed routing
4. Downtime tracking 
5. Production tracking and genealogy = Traceability (track products through their production cycle)

Following the best practices and international standards like ISA-TR88, we can build solutions that satisfy the above business needs. 

Let’s expand on just a few of them: 

The first is indispensable—that’s always the first step. We aim to get things connected and data flowing seamlessly to and from Ignition, and then we use that data to build the solutions that satisfy your user stories. 

The second one – OEE – is the star of the show. Everyone wants that, and for good reasons: it’s the embodiment of the “turn data into knowledge so you can change behaviours”. 



OEE is a fluffy topic, and there is no “right way” to do it. It highly depends on your situation. 

The last one – traceability – is becoming indispensable as well. With the recent EU regulations regarding carbon footprint and other environmental aspects, you’ll have to know your production cycle to a T and be able to track the steps a specific piece has gone through. 

4. Roll-out, change management, and training

We won’t abandon you at the roll-out, of course. The degree to which we’re involved depends on the magnitude of the solution and the preferences of the client to do it themselves or have local integrators do it on a specific site. Regardless, we’re there as consultants to make sure the rollout is successful.

The change management and training are ongoing. They happen incrementally, scheduled or not, and they sneak into the smallest details and shortest conversations. The goal is to keep people informed and engaged—how you get there often has to do with just being a reasonable human: a newsletter that announces the latest developments, a workshop that shows people the new Alarming features and how to use them, strong feedback loops, continuous communication etc. 

How we do it 



1. Discovery 

You bring in consultants because you expect them to have a fresh perspective, rooted in the bigger picture and the overall ecosystem of your company—plant floor and admin layer. You expect us to make sense of the problems and desires you have, and sort through them to set priorities.

A well-defined problem is half solved. In-person or remotely, we find answers to the most frequently asked questions:

• What do we want (and who’s “we”?)
• Why do we want it?
• Why don’t we have it yet?
• How are we currently doing things around here?
• What has to change for us to have it?
• How, in practical terms, do we get it?
• What stands in the way of that change?
• What do we have to do to overcome the obstacle in front of change?
• What’s the first objective?
• What’s the first practical step? 
• How do we get the relevant people on board to actually adopt the changes?
  

Then, based on experience and a bit of magic (insatiable passion for solving problems), we come up with a high-level roadmap that defines the immediate milestones, but also the long-term vision for scalability. 

Another caveat here: “long-term” is a dirty word in a digital transformation initiative. It’s not a straightforward project, and it’s prone to impossible-to-foresee changes. We have a vision, we have a plan to get there, and we also remain adaptable to what happens along the way. 

2. Prove the value 

We talked about this earlier in the article, so let’s just leave a story here. 

We flew to this large factory in Switzerland, and you know what happened? We skipped the abstract and fluffy 100-slide sales pitch deck (we’ve never had that anyway). 

Instead, with all the relevant stakeholders in the room, we got up from our chairs and walked to the whiteboard. Picked up a marker, turned around, and said: “ok, we’re here for 2 days. Let’s build something”. And together, we came up with a few requirements, some of them must-have, some of them nice-to-have. We agreed on the list, had lunch, had dinner, then went back to our hotel. 

The next day, we showed up with a working dashboard (not pretty, but working) that showed some data that solved a small problem. Needless to say, everyone was happy. And more importantly, relieved. 

Before leaving, the automation engineer in charge of the initiative told us that he liked our approach: practical, flexible, and realistic (meaning that we start small). 

As you see, we love doing workshops. Whether you prefer an in-person or a remote one, the principle is the same: build something to show the value of the initiative. Keep it under the radar, as small as possible, and build in parallel so you don’t disrupt the operation. 

3. Get started 

Together with the other pre-project steps (discovery and PoC), it’s likely the most important help we’re providing. And the technical talk is minimal. It’s mostly management, navigating corporate politics, human psychology, and negotiation. 

Why is this phase crucial? Well, let’s take just one element, like the business case: if you don’t build and present a good one, you don’t get the budget for the project. 

Identifying the specifications and requirements is also not as easy as one may think. Often, our clients think they know what they want and what they have, but it turns out there’s a more effective way for them. We help build the specs and tie them to the project’s goal. 

In any case, our purpose in this phase is clear: get started on the right foot. 

4. Scalable architecture 

With a scalable architecture, you can implement changes or upgrades to your system without disrupting ongoing production. This minimises downtime, ensuring continuous operations and maximising productivity. Essentially, you can add and remove elements (machines, lines, products etc.) from your production without overhauling the entire system. 

Getting this right from the get-go is important, so we make sure that happens.

Ongoing: Management & Support

Instead of getting into too many details about these, let us show you a picture of what a first work package looked like for one of our clients.

We broke down the project into separate work packages to reduce risks on their side (the Purchase department was very happy) and to make it easier to handle. Everything is planned on the forehand, documented, and part of a consistent feedback loop. 

Fast read: what’s in it for you 

Peace of mind

You don’t start from scratch and you feel more in control of the project’s outcome by having templates and a roadmap. 

Ownership of… everything

Many clients want to reach a situation where they can maintain and own everything themselves. Thanks to the non-proprietary nature of Ignition, our documentation, training, and template approach, you can easily maintain the solution(s) yourself and easily train new people to do it as well. 

Cheaper, faster

Because we don’t start from scratch, we deliver faster and require fewer engineering hours (thus, your cost is reduced) to get the job done. 

Before you go… 

Look, we’re not just aiming for that infamous “client satisfaction” that companies often pat themselves on their shoulders with, essentially bragging about making a promise and delivering on it, which is… you know… silly. It’s nothing out of the ordinary. It’s a given. Or it should be. It certainly is for us, which means that we aim even higher now, and the aim is your success. 

You are the person in charge of making this happen in your company, and the stakes are pretty high. You should be able to go to your stakeholders and say “hey, this is what we wanted to do, and we’ve done it”. You’re the hero of the story, not us—we’re just the guides who are happy to be involved and help you turn yourself into a success story. 

So, to increase the chances of that happening, we created the SCADA Project Framework. “Easy and enjoyable” means peace of mind in the face of a complicated SCADA project of a scary magnitude. It means reassurance that you hired a team that has a framework on what to do and how to do it, and the standardised, pre-made solutions, built from experience with similar projects in similar companies to yours, to get it all done faster and more effectively. 

Ready when you are.