关于软件容错设计，高手必进！！！！ (100分)

我目前设计一个工业测控程序，要求容错性极高，排除硬件出错几率，要求365天不间断
运行。我考虑采用双进程来实现，思路如下，请高手指正：
1、进程A启动后直接再启动一个进程B；
2、进程A和进程B以100ms为间隔进行通讯，A告知B还活着（呵呵）
3、如果进程B连续N（N>1）个100ms没有收到A的消息，就杀死进程A,接手运行，此时进程
B成为进程A,从1开始重复。
上面过程有什么漏洞，或者有更好的办法，请大家指正，谢谢！

不错[]

高手们，请发言

进程B先死了怎么办？

多谢ymail:
可以另外加上：
2.1:进程A如果连续N（N>1）个100ms没有收到B的消息，就杀之，重新创建进程B

我想比较麻烦！不如专门写个负责监视的程序：
A=应用程序
B=监视程序
B循环监视A是否运行，没有运行就重新运行。
B设为只有接受到关机信号时才允许退出或作为服务。

to lccc:
如果B=监视程序也死了呢？

如果进程创建失败怎么办？

AB都死了,呵呵,

为什么不用三模冗余TMR系统，建立三个进程，在加一个表决进程，表决进程设计的简单可靠。

如果A,b 都死了怎么办.

to sunshine_zk:
能详细谈吗？哪里有这方面的资料呢？

如果A,b 都死了,那就完蛋了。

时间冗余
在程序的适当位置设置若干检查点，在每一个检查点保存程序在该检查点之前正确运行而得到的全部信息及标志。如果故障是暂时性的则程序卷回到上一检查点开始重新执行，这样可以完全消除错误。它只能检出而不能消除永久性故障。
　　正确设置检查点非常重要，设置过多会使计算和检查点信息处理时间增加，设置太少又会使程序卷回太长。此外，对于实时控制系统中只允许执行一次的特殊过程不可重复。例如某些涉及输入、输出的操作。如图1所示。

to sunshine_zk:
程序中用到5ms定时器，现在的硬件基本能满足正常运行，每次(5ms)都设计输入输出，
回卷不是太容易

呵呵，这样的问题如果一直说进程A死了怎么办？进程B死了怎么办？这样问下去，就会是鸡
没有了怎么办？蛋先碎了怎么办？这样问下去是没有结果的。
要回答这样的问题，首先要问你的目标容错指标是什么？即你希望你的稳定性达到多少？
比如您是要求99.9%的时间可用，还是99.99%的时间可用，还是99.999%的时间可用。
（设你的系统可用性要求为U）
注意，算一下这里的东西，注意，如果要达到五个九，那就表示一年只有几分钟不可用。
这样高的安全性是很难达到的。所以，你首先要分析一下你一年内允许Down机时间是多少？
不要告诉我说不允许，那是不现实的，只能够出现在领导的不负责任的报告或是向上的公文中。

而且系统是一个综合的系统，你现在是假设硬件没有问题，但是，事实上，这个假设前提是不完备的。
我们应该有这样的几个假设：
操作系统是没有问题的。即排除操作系统出错。被控件的数据采集是安全的等待。

如果你还是假设这些问题都不考虑的情况下去考虑你程序本身的安全性的话，那么，就可以静下心来分析了。
按照你的思路：进程A进程B都在一台机器上，这样的安全性很脆弱，或者对于一个要求非常高的环境，
不应该这样做。因为这台机器出问题的可能性太高。因为这是会出现单点故障，即只要这个点出问题，
全系统完蛋。
更何况进程B是由进程A控制的，两者之间存在关联关系。两个有关联关系的点，在考虑安全性时，
应该将其视为一个点，而不是两个点。正是因为你是有关联关系的两个点，所以，才会出现上面朋友所问的：
如果A坏了怎么办？如果B坏了怎么办的问题。

这里提出一个建议：即对等在线备份的方案。
即存在物理A，B两台机器。
在A，B机器上分别有两个进程，一个负责独立地监控工控的被控机。另外一个进程负责
监控前一个进程。并及时向另外一个机器发送本机工控监视进程的状态。
正常情况下：A机的工控监视进程工作，而B机器的工控监进程处于Sleep状态。
A的进程监控程序不断发送正常消息到B机。B机在收到正常消息之后，返回确认消息。
如果A机收不到B机的确认消息，A机应该通过某种手段向系统管理员报警。（容错一）。
如果B机收不到A机的通讯，B机启动本机监控（此时A机监控可能工作正常），同时，
通过某种手段向系统管理报告A机工作不正常（容错二）。此时可能出现两台机器进行工控的情况。
当A机监控进程发现本机的工控进程不正常，即发送不正常信号到B机，同时向管理员报警。B机收到后，
即启动本机的工控收集进程，同时B机报警。双报警，以免一方报警失败。
当然，如果A机发现本机不正常，而且B机也启动不了本机的进程，呵呵，这就麻烦了。
这就是系统失效时间。
（一年总时间 - 失效时间）/一年的总时间=U
这个U就是你的系统可用性。这个U如果高于你最初对系统提出的要求，那么，这个系统就合格了，
虽然它有失效。
另外还要考虑一点响应速度。这也是系统整体性能应该考虑的因素。
这些意见仅从参考。如有不同意见，欢迎讨论。

做为软件开发人员或是开发商，在向用户承诺软件的可用性指标的时间，建议不要使用绝对不错出错，
一定没有事实要的武断的词句，如果你告诉用户，
我系统的可用性是95%，并且每次出错，如果可以修复，自动修复时间为:0.5s。
如果不可自动修复，系统管理员得到首次报警时间为10s。
如果用户分析之后，发现，工控采集如果少其中的0.5s数据不影响结果，并且在配备了系统管理
员24小时值班的情况下，人工修复时间不会超过30分钟的情况下，能够接受。那么，用户更容易接
受你的内容。不是很好么？

[]

精彩 Study

三模冗余TMR系统多都是用于硬件系统，我想应用于软件也是一样。在软件容错技术方面现在都还不是很成熟。

哦``````我懂了```````````````````````

《容错技术在控制系统软件中的应用》http://www.chinakong.net/asp/artical/list.asp?owner=3&Curpage=3