hez

 波及范围和影响梳理，我简单再总结下：
1、平时bob中低风险 或可控的开发，一般是基于特定芯片的某个测试项或者某几个测试项的改动，影响范围是这个芯片的某几个点，风险只在几个点范围内。
  通过动态库底层业务实现合站是需要底层改框架，而动态库的业务90%是硬件的业务，风险可能分布在全部芯片范围。

2、硬件的业务是硬件提出需求并推动验收，中试仪表相关的中试验收；通过动态库底层业务实现合站，是中试的需求影响的是硬件的校准业务； 
3、bob校准的系统测试其实依赖硬件的系统测试，之前的系统能保证硬件只审核一份日志就能对校准所有所有单板进行判断，通过动态库底层业务实现合站不能保证；
4、这个情景只可能在产线环境，所内校准环境跑不到，难验证充分；

其他实现路径:
问题主要出在产线的业务跨业务层打到动态库底层了。只要调用侧基于分层思想，把这块儿业务在外层封装就行了。
我粗略设想了下，除了上次讨论过的把函数改成进程封装来调用，还可以这样：两个进程A芯片校准进程、B芯片校准进程同时运行，
连接单板的时候根据要校准的芯片来决策哪个进程来连接单板。

 

------------------------------------

1、平时bob中低风险 或可控的开发是，一般是基于特定芯片的某个测试项或者某几个测试项，影响范围是这个芯片的某几个点。
通过动态库业务实现合站是需要底层改框架，而动态库的业务90%是硬件的业务，波及的范围可能是是全部芯片和测试项。

2、
硬件的业务是硬件提出需求并推动验收，中试仪表相关的中试验收。而业务上 ，因为底层都是

3、环境所内跑不到，导致验证不充分； 改后


不应该打chuan底层
3、方案：只要是基于分层思想的都可以，调用的时候做分层（动态库各个芯片都已支持）。 
在上层来调度两种芯片校准，

我初想了下，

 

 

1、风险你来担吗

2、软件分层的，

你一个产线的需求为啥要考虑 从底层入手呢，我们是针对所有产线的。大家都来增加隐患