Solution Architecting to Reduce Cost.

Solution Architecting to Reduce Cost.

Appomax rarely loses a bid to a direct competitor. Most of the time the most significant obstacle, here in Thailand, are the customers' budget. So it's no surprise when we designed a Centralised Solar Monitoring solution for a customer and was flatly told that, "It's beyond our budget"

The customer is a company that builds solar roofs and solar farms. They operate some to sell electricity to manufacturers and industrial estates or sell them off to make a profit.

The customer wishes to do a Proof of Concept with 8 sites with various sizes ranging from 0.52MW to 18MW and a total of 243 Inverters; so a mixture of size S, M, and L.

The monitoring solution requires

  • Summary Overview Dashboard
  • Site monitoring dashboards
  • Alarms
  • Reports

Overview Dashboard
Real-Time Raw Data
Data Logger Report
KPI Calculations
Excel Report with Charts
Conditional Alarms
Example Widgets
SCADA Style Process Flow Dashboard

Here is what we designed


  1. All the required modules to fulfil the requirements
  2. Ignition Edge IIoT utilises the Ignition Gateway Network, sending the Remote Tags Provider to the Central Gateway. It is edge-driven and costs 900USD per sight along with the EdgeBox RPI-200 from Seeed Studio (CM4, 4GB RAM, and 32GB SSD)
  3. AWS EC2 Linux server with enough computing power
  4. Amazon Aurora PostgreSQL - high-performance managed database

It seems like a perfect solution that meets all the requirements... except the cost.

I envy SI in places where the customers are fine with the Ignition's price tag, but I am in Thailand and used to seeing the customers' reaction when I show them the price.

So... do we give up? Of course not. We then swap out components and re-engineer a lower-cost solution.


Here is what we came up with

N3uron's solution

  1. Flutter Web App and Native Mobile App, for which we can develop minor custom features and embed N3uron Web Vision and Business Intelligence app.
  2. Similar edge layout, similar cost with N3uron's Link feature replacing the Gateway Network. It does precisely the same thing.
  3. The infrastructure for the MongoDB Historian is significantly cheaper than Ignition's SQL-based Tag Historian. (but we have to manage MongoDB by ourselves instead of using the AWS-managed database)
  4. This could have been a single server solution, but the database infrastructure cost saving allowed us to split the server into the front-end and back-end servers.
  5. Five N3uron Remote Licenses are needed (could get away with 4), somewhere between 9,360USD and 11,700USD. This is the end user's price; Appomax will get a partner discount and a volume discount =)
  6. Reporting was a significant concern as N3uron doesn't have a reporting module like Ignition. I will discuss our brainstorming process and options in another article, but here is our solution...

For Reporting, we decided to use Nuron's Scripting module to call the API Server, get the aggregated Historian Data, pre-calculate the values, and store all the processed data in an SQL Database.
We can use a BI tool like Amazon Quicksight to generate the report; depending on how complex the report is, we can also programmatically create the final reports.

The initial feedback from the customer is that the new cost is something they can "work with" and will compare the solution to other vendors.

I know this is not a 'clean' solution, but... needs must.

It is harder to integrate and maintain, but a 35-40% cost reduction gets us closer to the finish line.

Opinions, questions and suggestions are welcomed.

Richard Shaw

Staff Digital Transformation Engineer at Smith & Nephew

8 个月

Thanks for sharing! It's always interesting to see real architecture over demos. I believe HiveMQ Edge is free and does Modbus, but that wouldn't solve the backend problem. Also, does AWS have a Postgres/TimescaleDB option like Azure? It also makes a good historian.

回复
Rutger Van Aelst

Building scalable solutions for flexible manufacturing

8 个月

Thanks for sharing Vikan, I always like how open you are about your quotes and architectures! As you mention yourself the second option will be harder integrate and maintain, so I wonder what the TCO would be for both architectures. Some other remarks/questions: - Why do you need the SQL bridge module? I'm all for it by the way, making integration and maintenance easier it quickly pays for itself, but doesn't seem essential to me. - Do they need unlimited clients? Especially for a POC you might be able to start smaller - You could drop the Ignition reporting module and use a 3rd party reporting/BI tool - If you add Ignition BasicCare you should also add N3uron S&M I think the price could be a lot closer this way. Another thing to consider is cloud costs when running on AWS. I'm not a cloud expert by any means, but I know the big 3 aren't the cheapest. Also here you pay for convenience. Open source solutions like the MING stack and AnywhereSCADA or FUXA might be interesting too, especially if if keeping CAPEX down is the priority. By the way I'm also looking into N3uron and I think it definitely has its use cases! I often find Ignition to be an easier sell though because of the install base and available resources.

要查看或添加评论,请登录

Vikan Chirawatpongsa的更多文章

社区洞察

其他会员也浏览了