EAP 一直是我们的老本行，写了多个版本的 Driver 和 EAP 以后，今年发现有必要把这个老掉牙的应用再提升一个档次，和现代应用接轨。

由于 SEMI 标准的原因，EAP 和设备的连接架构一直是无法进行突破和改变的，至少在没有人愿意去实现 HSMS-MS （MS = MultiSession），HSMS-SS 注定就只能做点对点，高可用性只能建立在EAP 有多稳定（而不能用服务器集群来实现）。

EAP 能有什么突破呢 ？下面是一些考量：

1）软硬件独立

也就是在任何软件 （Linux/Windows）和硬件下 （x86/ARM)都能执行 （意昂娱乐3两年前就有了 Python/C 版本的 EAP）

2）图形化设计界面

利用类似 WorkFlow 的方式来设计 EAP 逻辑。其实二十年前就有了，连 Yokogawa 都有类似的解决方案。但没有一个产品能够完全的让客户不需要写代码，WorkFlow + 代码造成的结果就是 Debug 和改动困难。

3）部署方式

IoT 管理平台式的设备管理，如何提供统一的管理界面和新一代的 EAP，不止是 EAP 系统监控而是延伸到类似手机的 OTA 升级，甚至是不同版本的管理。

其中"3）部署方式"对客户的帮助是最大的，想象一下，一键安排 100 台 EAP 服务的 OTA 升级，系统会根据 EAP 的执行状态（例如正在执行生产必须要等到批次结束才可以）自行进行升级。这个把 IT 的工作，大幅度的简化了。

在继续之前，我们先定义好到底 EAP 有多少个组件 ？

1）Driver

也就是我们统称的 SECS/GEM Driver，主要实现了 SEMI 的各种不同标准（例如 E04，E05, E37 等）

2）EAP

这里指的是实现客户的运作逻辑，例如和 MES 的互动，Recipe 上传下载等。

3）客户端

不论是全自动或半自动，多少都需要操作人员做一些确认，客户端就是他们的界面。

一般上 Driver 和 EAP 是同一个程序（用 Windows 的角度，他们跑在同一个 EXE 中）。

我们对现在市面上的 EAP 系统（从老牌的 StationWork 一直到国产 EAP）进行了调研，主要集中在部署方式，以下是我们的一些发现：

1）部署方式一

EAP/Driver 以 Console 或 Windows 的方式执行在服务器，客户端在现场电脑通过 MessageBus 和 EAP 沟通。

2）部署方式二

EAP 和 Driver 分别以 Console 或 Windows 的方式执行在服务器，EAP/Driver/客户端通过 MessageBus 沟通。

3）部署方式三

EAP/Driver/客户端同时执行在现场电脑。

“1）部署方式一”和 “3）部署方式三”是通用的部署方式，两者的优缺点如下：

1）部署方式一

优点：

升级比较方便（在服务器上就可以了）

缺点：

1、隔离性不好（服务器出事，例如中点，全场 EAP 就掉线了）

2、管理上不方便（例如 100 个 EAP 程序，以 Console 或 Windows跑在一台服务上，不好找到哪一个 EAP 对应哪一些设备）

2）部署方式二

优点：

隔离性佳（单一 EAP 程序不会影响其他 EAP）

缺点：

升级不方便（一般是要到现场才能进行，或读程登陆多次）