EcoStruxure is Schneider's umbrella, and under it sit two software tracks that solve genuinely different jobs: Machine Advisor — a cloud SaaS subscription (ESEMALCZTSXAZZ-class part numbers) that watches machines and reports their health — and Automation Expert — a perpetual engineering license (EALBTP23 class) for building control logic on the IEC 61499 model. Confusing the two is a purchasing-category error: one is operations spending on visibility; the other is engineering spending on construction.
Machine Advisor: the machine's medical chart
The Machine Advisor track connects machines — Schneider or third-party — to a cloud service that collects their status, events and KPIs, and returns dashboards, alerts and maintenance views. Its unit of purchase is the subscription per machine or per year, and its value arrives without programming: connect, map the data points, get visibility. For OEMs offering service contracts and plants that want OEE and alarms without a middleware project, it is the fastest honest path to machine-level intelligence.
Automation Expert: building with distributed logic
Automation Expert is the engineering track: IEC 61499's distributed function-block model, where control applications compose across devices rather than centralize in one PLC. Its unit of purchase is the license (perpetual, single-seat engineering), and its value arrives through architecture: control distributed to the edge devices that own the I/O, resilient to central failure. It is for teams building new control architectures, not for teams watching existing ones.
The decision rule
Watch what exists — Machine Advisor, subscription. Build what's next — Automation Expert, perpetual license. Plants often run both eventually: the engineered estate feeds the monitored estate. Both tracks connect to the same controller base; neither changes the panel.
Is a cloud subscription a security risk?
A managed one, like any cloud connection: data leaves the plant, and the boundary device becomes critical. Machine Advisor's architecture publishes through a secured gateway with no inbound paths — the audit conversation is about your outbound policy, not about opening ports.
Why would I build on IEC 61499 instead of a PLC?
When the application is inherently distributed — many devices, local autonomy, graceful degradation — 61499's model puts logic where the I/O lives. When one controller honestly owns the job, a PLC is simpler; the standard earns its complexity on distributed problems.
