JDE IoT is easy, let's look at a use case and see how you can implement this solution.
Firstly, if you don't know how IoT can help you – think of something that you measure manually and let's automate that.
So, if you need to go and measure the temperature in a control room, then why not use a sensor to do this. Then you can have that measured all of the time. What about water quality? What about lidar to measure the height of a stack of coal? No worries!
At Fusion5, we've actually been through a process of designing this complete solution.
We have been using particle io boards to send sensor data to JD Edwards, but there is some cool tech in the middle.
We are using the particle 3G boards, like the boron below
but also dabbling with the latest mesh modules that they have released. These allow us to have less 3G, but more sensors.
This is allowing us to produce any device, using a myriad of sensors and being able to react to the data immediately.
The build at the moment is above, with a remote temp sensor and also a water proof and dust proof housing
Below is a set of devices for a PoC we've completed here in Australia. We have a couple of production POC's working with our JD Edwards clients.
These devices are waking up and sending temperature data & humidity data every 15 minutes to our particle cloud. We are using particle as the middleman, as the particle complete device solution (including data plan) is perfect. Added value is that if the power is disconnected, this also triggers an event that you can use to raise a work order, let's be honest – if the power goes, this is not good. The device has a battery which allows 2 weeks of disconnected data to be sent.
We are using 3G, as it does not create any holes in the client's networks. 3G also ensures that if the power goes out, we can still send the sensor data out to the cloud and react. Note that mesh devices can be connected to the 3G board, which extends its range without additional 3G data plans.
Simply, the diagram look like the above, but we need more layers to be future proof, there also needs to be some explanation to the logic layer. You can see that all of the items are standard and the JDE orchestrations are configuration not code. The solution is implemented without increasing your technical debt.
The above shows a little more detail of where we are adding strategic value, how this is an enterprise solution - not a tactical one. We use JDE for what it is good for – raising work orders or storing central data – it's not good for storing all of the trend data. We use cheap cloud storage (2.3 c per GB per month, or a massive 28 cents a year). Even with readings every 15 seconds and saying 256 bytes of data per read [date, time, GPS, temp, humidity], we are only going to store 24x60x4 - 5760 readings per day or 1.4 MB a day or 511MB a year per device. This means that you can store the data from 200 devices a year for about 28 dollars a year. You don't want to add 100GB to your JDE database do you?
You can see there are a number of items on this diagram. We are using public cloud (in many cases AWS lambda) in to run logic over the top of the data, we do this as an initial triage – as we don't want to call orchestrations every time we get a meter reading (read the numbers above).
The data is interpreted in this cloud logic layer, which then can determine whether a business rule has been breached and call and orchestration accordingly. Once again, the cloud costs of lambda are tiny and this is a cheap solution to run at scale.
Note that the values (actual breach values - high and low temperatures) ARE stored in JDE. So there is a single place to go to maintain the threshold data. The lambda functions query this on a scheduled basis – keeping everything fresh and efficient.
You'll also see mention of campfire in the diagram, this is a Fusion5 integration solution for enabling on premise software to be connected to the cloud. It's our super light middleware, that is no fuss and build on AWS highly available constructs. Highly available and disaster recoverable integration solution in the cloud!
All of the measurement data is being stored in a bucket (whether this is azure, google cloud storage or s3) to enable training AI down the track. Imagine pointing quicksight at your data, and extracting insights.
This is a complete solution that can scale to any number of devices. It delivers TRUE real-time ERP functionality – raising work orders when things get too hot – but also allows for future prediction analysis by providing the training data for AI. This AI can deliver true actionable insights back into JDE and perhaps raise work orders before something actually gets too hot (based upon all of the training data).
This is all decoupled from the ERP. This is all getting clients cloud ready. BUT, JDE is doing all of the things that it is great at!
We have a self service web portal that users can view any of the configured IoT devices:
This can easily be hosted as a cafe1 window and accessible from JDE
You can see from above, that all of the information is at your fingertips from JDE, perfect.
We can drill down to the history too
This is all enabled with a simple orchestration and cafe1 pages.
You also don't need JDE, we have the capability to call "webhooks" that can really go to anywhere, but also use campfire to call bespoke and on premise functionality.
Fusion5 and the innovation team are plugging in IoT and also the ability to embrace AI into our ERP. This implementation means clients are not making large capital investments, and you are able to prototype these quickly and easily.
Devices are costing $150 each, data subscriptions are around $5 a month and then cloud costs (logic and website hosting) are costing another $5 a month. Sure, the consulting might cost something, but you can see that the ongoing investment is minimal!
If you want to plug IoT into your JDE in a strategic way, Fusion5 would love to help!
