83 lines
5.0 KiB
Markdown
83 lines
5.0 KiB
Markdown
|
# EqpALG
|
|||
|
|
设备检测主程序
|
|||
|
|
|
|||
|
|
## 设计思想
|
|||
|
|
通过数学方式和固定规则，对数据进行整理和规约，最后根据习得的数据对新数据进行判断
|
|||
|
|
|
|||
|
|
## 模块信息
|
|||
|
|
主模块分为以下几个模块
|
|||
|
|
1. eqpalg 程序的入口
|
|||
|
|
2. eqpalg_ICEI 程序的交互
|
|||
|
|
3. gb_logger 进行全局log的logger，可以在主线程和子线程内都打印信息
|
|||
|
|
4. algorithm_manager 算法管理器，实际上程序的执行入口，控制和创建进程、分配指定的任务到目标进程
|
|||
|
|
5. algs 具体的算法实现，这一部分的实现，包含了检测开始条件和结束条件等
|
|||
|
|
6. distribution 分布系统，负责对数据数据进行分布分析，得到具体的分布类型和参数，并做存储
|
|||
|
|
7. regression 回归系统，同上
|
|||
|
|
8. stat_tools 统计模块，包含了对于分布、回归等模型的调用
|
|||
|
|
9. table_struct 数据库表结构（自定义）
|
|||
|
|
10. threads 三个子模块进程，包含在线模块(mon)、单次执行模块(task)、定时执行模块(cron)
|
|||
|
|
11. 在线模块包含模型的在线报警
|
|||
|
|
12. 单次执行模块负责执行设定在某个时间段中的数据
|
|||
|
|
13. 定时任务模块负责定时向带有取样的算法更新数据，以及劣化趋势分析
|
|||
|
|
|
|||
|
|
## 程序结构设计思想
|
|||
|
|
1. 上层逻辑需要高度抽象，具体实际实现由下层代码实现
|
|||
|
|
2. 不同进程公用算法的基本过程，由模板元编程控制对应的程序编译过程
|
|||
|
|
3. 新的算法尽量包含或继承现有算法，减少代码量
|
|||
|
|
4. 如果一个新算法没有和其它算法具有公共过程，就直接继承AlgBase
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 代码规范
|
|||
|
|
1. 程序代码规范参考谷歌C++代码规范，但是函数命名使用了C的方式，之后可以统一为驼峰式
|
|||
|
|
2. 新的代码优先考虑OOP和FP的组合，尽量不要出现大段面向过程代码
|
|||
|
|
3. 可复用的逻辑必须独立为函数或类，供其它部分调用
|
|||
|
|
4. 不同功能的部分，需要在主目录下新建不同的文件夹，作为不同的子文件夹
|
|||
|
|
5. 算法内部逻辑设计时，优先考虑使用状态机检验正确性
|
|||
|
|
6. 对于有限的泛化模板逻辑，最好在生成对应的cpp文件，并将其实现写出，以加速编译
|
|||
|
|
7. 对于异常处理，目前使用嵌套异常，来生成异常的产生堆栈，建议以后继续这种写法
|
|||
|
|
8. 对于多线程，优先考虑线程安全性，而不是性能
|
|||
|
|
9. 对于可以预测的数据异常，必须做相应的处理
|
|||
|
|
|
|||
|
|
## 目前的问题
|
|||
|
|
### 等待解决
|
|||
|
|
1. 表达式-取样算法中，阈值设置问题（数学问题）
|
|||
|
|
2. 算法分布类型判断不准确问题（数学问题）【正在处理中】
|
|||
|
|
3. 较为严重的第一类错误和第二类错误问题（数学问题）
|
|||
|
|
4. 程序运行时间逻辑可能在启动时有误的问题（程序问题）【正在处理中】
|
|||
|
|
5. 偶发性ihyperDB查询失败的问题（程序问题）
|
|||
|
|
6. 程序长时间运行可能出现无法恢复的异常（程序问题）【正在处理中】
|
|||
|
|
7. 部分不重要算法暂时未迁移，在.do_not_use/alg_to_transfer下（程序问题）
|
|||
|
|
8. 部分程序模型对应有误（主要问题）
|
|||
|
|
9. 部分数据源有误（数据源问题）
|
|||
|
|
10. ihyperDB自身出错导致的异常（数据源问题）
|
|||
|
|
### 可以解决，但是由于不方便，暂时没有解决的问题
|
|||
|
|
1. 系统的时间和用户时间不同步，导致报警时间无法对应的问题——同步所有系统和用户的时间
|
|||
|
|
2. 系统的共享内存数据存储在~/glbarea下，如果删除了该目录下的文件，会导致所有共享内存操作出现异常，包括但不仅限于：
|
|||
|
|
1. 机组号前缀(CMemVar::Const()->UnitNo)无法取得，导致zhd数据缺少前缀，全部插入错误（联系邹大师说明问题）
|
|||
|
|
2. 机组号前缀(CMemVar::Const()->UnitNo)无法取得，导致程序内TAG点数据查询全部错误（程序内通过config写死，迁移再更改）
|
|||
|
|
3. 程序的内存缓存数据获取会出现异常（删除1分钟之后再启动本程序）
|
|||
|
|
3. 极其偶发的共享内存的数据异常，这个可能是由于多线程引起的 （校验数据值，确定在正常范围内再使用）
|
|||
|
|
4. IHDB时间异常【已经解决，但是是通过本地计算queried_time时间解决的，最终导致时间可能和实际时间不一致，具体代码在mix_cc/ihyper_db下面】
|
|||
|
|
5. 部分模型错误已经指出（没时间更改）
|
|||
|
|
|
|||
|
|
## Todo
|
|||
|
|
1. 修正已知的无效模型
|
|||
|
|
2. 增加新的有效模型
|
|||
|
|
3. 增加每周的周报（设备劣化）【正在处理中】
|
|||
|
|
4. 新的机组数据增加
|
|||
|
|
5. 后续的项目迁移
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 编译环境
|
|||
|
|
1. 编译器需要gcc10以上，不要使用clang和libc++，因为iPlature不支持
|
|||
|
|
2. cmake建议3.20以上
|
|||
|
|
3. dlib 默认最新稳定版即可
|
|||
|
|
4. boost 1.75以上
|
|||
|
|
5. eigen3
|
|||
|
|
6. 建议使用vcpkg用作包管理
|
|||
|
|
|
|||
|
|
## 项目未来展望问题
|
|||
|
|
1. 任务种类和数量太多，人员太少，建议每日逐个完成，并且不要加班，如果后续有新人加入，为不同类型的新人分配不同任务
|
|||
|
|
2. 项目缺乏数学思想指导和报警数据集，建议在这两点上面做文章
|
|||
|
|
3. 多写单元测试
|
|||
|
|
4. 如果后续有足够人手，一定要把程序编写和模型编写实现的人手分开
|