Fox-Edge项目是定位于 数字化运营 的一款边缘计算平台。
在 数字化运营 领域，数据 是整个领域的中心，而 数据获取 又是重中之重。
在数字化运营领域，如果按设备的 种类 和 数量 ，两个维度进行划分，数字化运营项目实际上 又可以分为两大类，行业内并没有统一的称呼，灵狐姑且先按 重装项目 和 敏捷项目 来称呼它们。
这类项目的关注点是 数据密集处理 ，一个项目的虽然设备的种类并不多，但是它们的数量非常众多。 代表性的行业，比如水电煤气的三表项目。几千个设备只是入门，几万只设备是刚开始，通常一个城市就有几十万、几百万仪表。
这类项目的关注点是项目实施中如何 快速响应客户现场的设备接入需求 ，这类项目中的设备数量几十个、上百个以内，但是设备的款式非常众多，而且种类可能随时会更换。 代表性的行业，比如有消防领域，虽然它们的设备总数少，可种类多。
Fox-Edge 提供了JAR引擎 和 JSP引擎 的双引擎的技术方案，用于针对上述两种不同类型的项目。
灵狐在进行Fox-Edge的时候，一开始侧重的是数据密集型的重装项目，所以在 解码器引擎 的关键技术上， 选型的是动态装载JAVA的静态JAR包的方案。
这种方案的好处，就是JAVA作为一种静态语言，性能非常好，能够大规模的密集处理数据。 比如，你在灵狐的演示之中，一款小小的设备，都能密集处理1000台模拟设备，10万个模拟采样数据。
但是，JAR引擎作为静态方案，它使用新款解码器的时候，是要重启JAVA进程来加载新的解码器JAR包的。 虽然JVM支持JAR包的动态加载，但是毕竟JAVA是一种 静态语言 ，涉及到进程安全，JAR在运行期是不允许变更的。
JAR引擎可以做到 即插即用 ，但是做不到 即改即用
敏捷项目，它们在单个项目中的设备并不多，而设备种类却非常多，而且设备接口还可能会来回变化。
在面对这种场景，JAVA JAR引擎的高性能优势不但派不上，还因为静态特性，跟不上这类项目实施的节奏。
敏捷项目就迫切需要一种立足于 动态语言 的解码器引擎，最终达到 即改即用 的目的
JAVA的JVM提供了 ScriptEngine ，来支持运行脚本类语言在它之中进行执行。 灵狐立足于ScriptEngine技术，选择了 JavaScript 作为动态语言，来支持敏捷项目对项目的即改即用诉求。
作为解码器引擎，JSP引擎同样有自己的约定，作为使用规范。
每一个设备型号的定义，均包括 设备厂商 和 设备类型，作为设备唯一性标识。
一种设备型号，可以包括一组跟设备之间的操作接口，在Fox-Edge中，称它们为 操作方法 。
设备的每一个操作接口，都对应一个操作方法。比如读取电压操作，读取电流操作，读数据操作。
设备的接口，根据它们的行为模式，可以分为 问答操作 、 上报操作 、发布操作 三种模式。
指的是主从半双工类设备提供的接口，它严格要求一问一答的方式，这也是最常见的交互方式。
指的是对等通信设备下，由设备主动向上位机发起通信报文，上位机对这个报文只负责接收的方式。
指的是对等通信设备下，由上位机主动向设备发起通信报文，设备对上位机的报文只负责接收的方式。
Fox-Edge在用户定义操作方法方法的时候，也相应定义了这三种模式。
设备的返回数据，按Fox-Edge的分类，有状态数据、记录数据、确认结果，这三种模式。
一个对象，数值数据来回变化更新，依然只有一个数据对象，该数据只是反复的在刷新。
比如温度、湿度。你对它们进行一百次采样，它们依然是一个对象，只是更新了一百次。
它们的数据，会被存储在Redis的设备状态之中。
数据格式是一个对象格式的JSON结构
{
"温度": 23,
"湿度": 75
}
一个对象，每天来回产生大量的不同数据记录，它跟着会产生很多增量记录
比如门禁的员工打卡记录，告警记录。
它们的数据，会被存储在MySQL的设备记录表之中。
数据格式是一个列表格式的JSON结构
[{
"event": "刷卡进门",
"cardId": "34f2bf4b",
"datetime": "2007-03-13 12:58:38",
"recordType": "刷卡记录"
}, {
"event": "刷卡出门",
"cardId": "34f2bf4b",
"datetime": "2007-03-13 14:21:44",
"recordType": "刷卡记录"
}]
用户开关某个信号，设备会应答确认/拒绝，这种信息仅仅对这个会话有效，并不应该产生记录。
比如，用户对门禁设备执行开门动作，门禁设备返回是否执行成功。
它们的数据，作为会话操作结果，根据是否要进行记录，被记录到MySQL的用户操作记录表中，或者不保存操作记录。
{
"操作成功": true
}