660MW燃煤机组DCS国产化改造方案研究

某电厂为4*660 MW空冷燃煤超临界火电机组,其3号机组主机DCS控制系统采用美国艾默生ovation3.5.0系统,辅助外围系统采用新华XDC800B系统。随着外部形势变化,近几年来国产DCS系统硬件质量的提升,国产DCS系统在超临界、超超临界火电机组上自主可控的趋势越来越明显,大型火电机组DCS控制系统改造也越来越具备规模性。以其3号机组DCS控制系统改造升级为国电智深的EDPFNT+系统,提出了详细具体的实施方案,同时完善了工控网络安全相关系统方案和要求等,以期为火电厂DCS控制系统改造提供借鉴参考。     

电厂用分散型控制系统的画面设计

一、概述当前,越来越多的电厂使用分散型控制系统(DCS),由原来的600MW、300MW机组到现在的125MW、100MW机组都在逐步推广使用.由于DCS的应用,机组数据的显示、操作、记录等都要通过计算机的外部设备(CRT、键盘、鼠标器、打印机等)完成,以取代原来的常规仪表.另外,由于DCS的使用,使得机组的自动化程度越来越高,而且DCS的可靠性不断提高,操作员对计算机的依赖程度也不断提高,从而CRT画面质量的好坏直接影响DCS的使用效率.如果一套DCS的CRT画面安排得不尽合理,那么这套DCS是很难发挥出其最大功效.所以,有必要对每一幅CRT画面进行优化设计,并对所有的     

推进国产DCS应用进程的探讨

本文浅析了分散控制系统(以下简称DCS)在火电厂发电机组控制中的地位,介绍了国内火电机组主设备和辅网控制系统的应用调研情况,分析了全厂辅控网采用DCS的优势。在对国产DCS应用可靠性、技术与能力、价格水平、与进口DCS的差距等,进行综合分析研究的基础上,提出了推进机组DCS国产化的建议。     

DCS系统时钟同步及跳变机制研究与改进

福清核电站采用了先进的全厂数字化（DCS）控制系统,作为分布式实时系统,对时钟信号的处理提出了非常高的要求。文章针对DCS时钟同步及时钟跳变机制进行相关研究,并结合福清1号机组出现的上游时钟跳变对DCS系统产生的影响,研究上游时钟发生跳变时DCS系统的应对机制,通过自主搭建的时钟授时DCS系统开展系列测试,提出并实现了两种预防DCS系统时钟跳变对DCS影响的改进方法,消除了上游GPS时钟跳变对DCS系统的影响,避免因上游时钟跳变后DCS不可用造成的机组非计划后撤,本研究对核电厂机组安全稳定运行具有实际应用价值,并对后续机组及同行电厂DCS时钟同步机制研究具有借鉴意义。     

DCS在中小型循环流化床机组自动化控制中的应用

从工程实际出发,对中小型循环流化床机组自动化控制进行了探讨。本文站在DCS控制的角度,分别从DCS控制必要性、循环流化床汽轮发电机组DCS控制等方面,就如何以科学、合理的方式,实现适合中小型循环流化床机组的DCS控制,阐述个人的一点体会。     

600MW机组仿真机的虚拟DCS系统开发

对火电机组分散控制系统（DCS）的仿真采用先进的虚拟DCS技术,这样可以在仿真机中实现对机组DCS系统中控制逻辑和控制策略的全仿真,除能对运行人员和热控人员进行培训外,还具有对真实DCS系统进行调试与优化的先进功能.以安徽平圩发电有限公司600MW机组的FOXBORO I/A Series DCS系统为虚拟对象,介绍600MW仿真机虚拟DCS的系统结构和开发过程,其中主要介绍了虚拟DCS的核心代码的实现.     

火电厂控制系统发展探究

DCS是火力发电厂的控制核心部分，直接体现机组的自动化水平的高低，关系机组是否安全、经济运行。本文分析PLC、DCS、FCS的各自的技术经济特点，分析它们各自功能的扩展和技术的发展趋势；分析整合PLC、DCS、FCS组成一个配置更加优化，覆盖监控、管理、决策功能的，彻底分散化、网络化的高水平现代控制系统的发展前景，并探讨FCS在百万机组中的应用前景。     

和利时中标大唐吉林辽源电厂2X 330MW新建机组DCS项目

近日，和利时首次中标东北电力300MW以上大型电力机组的DCS系统，即大唐吉林辽源电厂2X330MW新建机组DCS项目。这两台供电机组是吉林市委、市政府十分重视的项目，是拉动辽源经济发展的重点项目。预计2008年末第一台机组投产，2009年一季度实现“双投”。     

DCS系统常见故障分析及处理措施探讨

随着自动化程度的日益提高,大型火电机组对DCS系统的依赖性也越来越高。如何提高DCS的可靠性作为一个重要课题摆在了热控人员的面前。本文通过维护DCS的实践和同行经验的借鉴,对DCS系统网络通信故障、软硬件故障和系统电源故障现象、危害进行了分析和研究,并根据有关规程提出有针对性防范措施。对火电机组的DCS系统安全运行、日常维护和技术监督有一定的参考作用。     

DCS分布式处理单元及其散热风扇供电设计优化

分布式处理单元是DCS系统中最重要的组成部分,其供电可靠性的设计直接影响到DCS系统的安全稳定运行。主要分析了某核电厂1、2号机组非安全级DCS控制柜内分布式处理单元与散热风扇不满足单一故障准则,并结合现场项目建设进展,通过对目前控制柜内分布式处理单元及散热风扇供电设计进行分析,从可靠性、机组安全性和经济性角度对原有设计提出优化方案,并推动该方案在1、2号机组完成改造实现,为后续核电机组DCS系统提供参考和借鉴。     

Do bugs foreshadow vulnerabilities? An in-depth study of the chromium project

As developers face an ever-increasing pressure to engineer secure software, researchers are building an understanding of security-sensitive bugs (i.e. vulnerabilities). Research into mining software repositories has greatly increased our understanding of software quality via empirical study of bugs. Conceptually, however, vulnerabilities differ from bugs: they represent an abuse of functionality as opposed to insufficient functionality commonly associated with traditional, non-security bugs. We performed an in-depth analysis of the Chromium project to empirically examine the relationship between bugs and vulnerabilities. We mined 374,686 bugs and 703 post-release vulnerabilities over five Chromium releases that span six years of development. We used logistic regression analysis, ranking analysis, bug type classifications, developer experience, and vulnerability severity metrics to examine the overarching question: are bugs and vulnerabilities in the same files? While we found statistically significant correlations between pre-release bugs and post-release vulnerabilities, we found the association to be weak. Number of features, source lines of code, and pre-release security bugs are, in general, more closely associated with post-release vulnerabilities than any of our non-security bug categories. In further analysis, we examined sub-types of bugs, such as stability-related bugs, and the associations did not improve. Even the files with the most severe vulnerabilities (by measure of CVSS or bounty payouts) did not show strong correlations with number of bugs. These results indicate that bugs and vulnerabilities are empirically dissimilar groups, motivating the need for security engineering research to target vulnerabilities specifically.     

ELBlocker: Predicting blocking bugs with ensemble imbalance learning

ContextBlocking bugs are bugs that prevent other bugs from being fixed. Previous studies show that blocking bugs take approximately two to three times longer to be fixed compared to non-blocking bugs.ObjectiveThus, automatically predicting blocking bugs early on so that developers are aware of them, can help reduce the impact of or avoid blocking bugs. However, a major challenge when predicting blocking bugs is that only a small proportion of bugs are blocking bugs, i.e., there is an unequal distribution between blocking and non-blocking bugs. For example, in Eclipse and OpenOffice, only 2.8% and 3.0% bugs are blocking bugs, respectively. We refer to this as the class imbalance phenomenon.MethodIn this paper, we propose ELBlocker to identify blocking bugs given a training data. ELBlocker first randomly divides the training data into multiple disjoint sets, and for each disjoint set, it builds a classifier. Next, it combines these multiple classifiers, and automatically determines an appropriate imbalance decision boundary to differentiate blocking bugs from non-blocking bugs. With the imbalance decision boundary, a bug report will be classified to be a blocking bug when its likelihood score is larger than the decision boundary, even if its likelihood score is low.ResultsTo examine the benefits of ELBlocker, we perform experiments on 6 large open source projects – namely Freedesktop, Chromium, Mozilla, Netbeans, OpenOffice, and Eclipse containing a total of 402,962 bugs. We find that ELBlocker achieves F1 and EffectivenessRatio@20% scores of up to 0.482 and 0.831, respectively. On average across the 6 projects, ELBlocker improves the F1 and EffectivenessRatio@20% scores over the state-of-the-art method proposed by Garcia and Shihab by 14.69% and 8.99%, respectively. Statistical tests show that the improvements are significant and the effect sizes are large.ConclusionELBlocker can help deal with the class imbalance phenomenon and improve the prediction of blocking bugs. ELBlocker achieves a substantial and statistically significant improvement over the state-of-the-art methods, i.e., Garcia and Shihab’s method, SMOTE, OSS, and Bagging.     

An empirical study of supplementary patches in open source projects

Developers occasionally make more than one patch to fix a bug. The related patches sometimes are intentionally separated, but unintended omission errors require supplementary patches. Several change recommendation systems have been suggested based on clone analysis, structural dependency, and historical change coupling in order to reduce or prevent incomplete patches. However, very few studies have examined the reason that incomplete patches occur and how real-world omission errors could be reduced. This paper systematically studies a group of bugs that were fixed more than once in open source projects in order to understand the characteristics of incomplete patches. Our study on Eclipse JDT core, Eclipse SWT, Mozilla, and Equinox p2 showed that a significant portion of the resolved bugs require more than one attempt to fix. Compared to single-fix bugs, the multi-fix bugs did not have a lower quality of bug reports, but more attribute changes (i.e., cc’ed developers or title) were made to the multi-fix bugs than to the single-fix bugs. Multi-fix bugs are more likely to have high severity levels than single-fix bugs. Hence, more developers have participated in discussions about multi-fix bugs compared to single-fix bugs. Multi-fix bugs take more time to resolve than single-fix bugs do. Incomplete patches are longer and more scattered, and they are related to more files than regular patches are. Our manual inspection showed that the causes of incomplete patches were diverse, including missed porting updates, incorrect handling of conditional statements, and incomplete refactoring. Our investigation showed that only 7 % to 17 % of supplementary patches had content similar to their initial patches, which implies that supplementary patch locations cannot be predicted by code clone analysis alone. Furthermore, 16 % to 46 % of supplementary patches were beyond the scope of the immediate structural dependency of their initial patch locations. Historical co-change patterns also showed low precision in predicting supplementary patch locations. Code clones, structural dependencies, and historical co-change analyses predicted different supplementary patch locations, and there was little overlap between them. Combining these analyses did not cover all supplementary patch locations. The present study investigates the characteristics of incomplete patches and multi-fix bugs, which have not been systematically examined in previous research. We reveal that predicting supplementary patch is a difficult problem that existing change recommendation approaches could not cover. New type of approaches should be developed and validated on a supplementary patch data set, which developers failed to make the complete patches at once in practice.     

岭澳二期核电站传感器故障行为分析

以岭澳二期核电站数字化仪控系统DCS为背景,介绍了在此基础上开展的传感器故障分析工作,通过实例介绍了岭澳二期DCS缺省值分析和实现方法。对于传感器信号漂移问题,提出了偏差报警的设计方案。文中的分析方法对指导DCS设计,提高DCS的可靠性有重要意义。     

DCS系统的功能特点及采购方式

简述了DCS系统的功能特点、应用情况以及今后的发展方向;简要分析了DCS系统两种采购方式的优缺点.     

High-Impact Bug Report Identification with Imbalanced Learning Strategies

In practice, some bugs have more impact than others and thus deserve more immediate attention. Due to tight schedule and limited human resources, developers may not have enough time to inspect all bugs. Thus, they often concentrate on bugs that are highly impactful. In the literature, high-impact bugs are used to refer to the bugs which appear at unexpected time or locations and bring more unexpected effects (i.e., surprise bugs), or break pre-existing functionalities and destroy the user experience (i.e., breakage bugs). Unfortunately, identifying high-impact bugs from thousands of bug reports in a bug tracking system is not an easy feat. Thus, an automated technique that can identify high-impact bug reports can help developers to be aware of them early, rectify them quickly, and minimize the damages they cause. Considering that only a small proportion of bugs are high-impact bugs, the identification of high-impact bug reports is a difficult task. In this paper, we propose an approach to identify high-impact bug reports by leveraging imbalanced learning strategies. We investigate the effectiveness of various variants, each of which combines one particular imbalanced learning strategy and one particular classification algorithm. In particular, we choose four widely used strategies for dealing with imbalanced data and four state-of-the-art text classification algorithms to conduct experiments on four datasets from four different open source projects. We mainly perform an analytical study on two types of high-impact bugs, i.e., surprise bugs and breakage bugs. The results show that different variants have different performances, and the best performing variants SMOTE (synthetic minority over-sampling technique) + KNN (K-nearest neighbours) for surprise bug identification and RUS (random under-sampling) + NB (naive Bayes) for breakage bug identification outperform the F1-scores of the two state-of-the-art approaches by Thung et al. and Garcia and Shihab.     

基于时序模型的Bug数的分析与预测

在大型软件测试中,发现的Bug数是一个随机时间序列,没有固定的数量规律,但可以借助数学模型研究Bug的数量关系.通过对实际的大型软件开发项目中的Bug数的整理和分析,建立了ARMA(p,q)模型,使用该模型可以预测Bug数,并从中发现软件开发过程中存在的质量控制问题.     

Understanding the triaging and fixing processes of long lived bugs

ContextBug fixing is an integral part of software development and maintenance. A large number of bugs often indicate poor software quality, since buggy behavior not only causes failures that may be costly but also has a detrimental effect on the user’s overall experience with the software product. The impact of long lived bugs can be even more critical since experiencing the same bug version after version can be particularly frustrating for user. While there are many studies that investigate factors affecting bug fixing time for entire bug repositories, to the best of our knowledge, none of these studies investigates the extent and reasons of long lived bugs.ObjectiveIn this paper, we investigate the triaging and fixing processes of long lived bugs so that we can identify the reasons for delay and improve the overall bug fixing process.MethodologyWe mine the bug repositories of popular open source projects, and analyze long lived bugs from five different perspectives: their proportion, severity, assignment, reasons, as well as the nature of fixes.ResultsOur study on seven open-source projects shows that there are a considerable number of long lived bugs in each system and over 90% of them adversely affect the user’s experience. The reasons for these long lived bugs are diverse including long assignment time, not understanding their importance in advance, etc. However, many bug-fixes were delayed without any specific reasons. Furthermore, 40% of long lived bugs need only small fixes.ConclusionOur overall results suggest that a significant number of long lived bugs may be minimized through careful triaging and prioritization if developers could predict their severity, change effort, and change impact in advance. We believe our results will help both developers and researchers better to understand factors behind delays, improve the overall bug fixing process, and investigate analytical approaches for prioritizing bugs based on bug severity as well as expected bug fixing effort.     

CHECKERDROID : Automated Quality Assurance for Smartphone Applications

Smartphone applications'' quality is vital. However, many smartphone applications on market suffer from various bugs. One major reason is that developers lack viable techniques to help expose potential bugs in their applications. This paper presents a practical dynamic analysis tool, CheckerDroid, to help developers automatically detect both functional and non-functional bugs in their Android applications. CheckerDroid currently supports the detection of the following three types of bugs: null pointer exception, resource leak and sensor listener misusage. We built CheckerDroid by extending Java PathFinder (JPF), a widely-used model checker for general Java programs. Our extension addresses two technical challenges. First, Android applications are event-driven and lack explicit control flow information between event handlers. Second, Android applications closely hinge on native framework libraries, whose implementations are platform-dependent. To address these challenges, we derive event handler scheduling policies from Android documentations, and encode them to guide CheckerDroid to realistically execute Android applications. Besides, we modeled the side effects for a critical set of Android APIs such that CheckerDroid can conduct bug detection precisely. To evaluate CheckerDroid, we conducted experiments with seven popular real-world Android applications. CheckerDroid analyzed these applications in a few minutes, and successfully located real bugs in them.     

Extending mutation testing to find environmental bugs

Environmental bugs are bugs caused by limitations of precision or capacity in the environment of a piece of software. These bugs may be difficult to activate and even more difficult to find. This paper reports on an extension to traditional mutation testing that enables testing specifically for environmental bugs involving integer arithmetic. This method is both simple and effective, and provides some insight into other possible extensions of the mutation-testing methodology that can be used to expose environmental bugs.