Modeling and Verification of Safety-Critical Systems Using Safecharts

中科大－耶鲁高可信软件联合研究中心简介一、概述在中科大软件安全实验室和耶鲁大学FLINT实验室近五年合作的基础上，双方校长于2008年10月签署备忘录，以中科大软件安全实验室为基础，在中科大建立高可信软件联合研究中心。

该中心是在两校相关实验室多年合作的基础上建立的。

五年多来，我校软件安全实验室在耶鲁大学邵中教授的指导（包括和他主持的FLINT实验室的合作）下，研究水平上升较快。

在邵中教授的支持下，软件安全实验室多次获得国家基金面上项目的资助，目前正在合作申请“海外及港澳学者合作研究基金”。

在国际会议和国内外期刊上，两校研究生共同发表了7篇论文，我校研究生单独发表论文10多篇。

近6年在编程语言理论及实现技术、软件安全和软件形式验证等研究方向培养了18名博士，其中在高校当教师的有8人，在Intel、Microsoft和Sun公司研发部门工作的有6人，做博士后的有2人。

二、研究领域（1）程序设计语言理论和实现技术。

这是一个持续活跃了半个世纪的研究领域，目前国际上最活跃的方向是并行编程语言的设计和实现技术、程序验证技术等。

我们目前的研究集中在形式程序验证（formal program verification）和出具证明编译器（certifying compiler）两个方向上。

通过近几年的国际合作研究，研究水平上升较快。

（2）第2步拟展开的研究方向是计算机网络方面。

有待耶鲁大学相关教授来访，和华蓓教授（可见htttp:///~bhua）和董群峰教授等经过充分交流后展开。

在高可信软件研究领域，联合研究中心以形式程序验证为主要方法，研究提高软件可信程度的理论和技术等，目前正在开展的课题有系统软件的形式验证、出具证明的编译器技术、并发多核软件的开发、自动定理证明系统等在高可信软件研究领域，联合研究中心近5年的建设目标是：研究如何有效地集成形式程序验证和领域专用语言和逻辑（domain-specific languages and logics）这两种软件技术，形成提高编写高可信软件生产力、提高对它们正确性和安全性信任程度、并且能被工业界接受的软件开发新方法，构建基于此方法并能向工业界推广的开发携带证明大型系统软件的基础结构。

英语作文-集成电路设计行业中的人工智能与机器学习应用In the realm of integrated circuit (IC) design, the application of artificial intelligence (AI) and machine learning (ML) has emerged as a transformative force, revolutionizing the way circuits are conceived, optimized, and validated. This synergy between AI/ML techniques and IC design has not only accelerated the development process but has also significantly enhanced the performance, efficiency, and reliability of modern semiconductor devices.AI and ML technologies are particularly advantageous in IC design due to their ability to process vast amounts of data and derive complex insights that are difficult to ascertain through traditional methods. One of the primary areas where AI excels is in the optimization of circuit layouts and architectures. Designers can leverage AI algorithms to explore a myriad of design possibilities, considering parameters that range from performance metrics to power consumption and manufacturing costs.Moreover, AI enables predictive modeling with a level of accuracy that was previously unattainable. By analyzing historical design data and outcomes, machine learning algorithms can predict potential issues early in the design phase, thereby minimizing costly redesigns and ensuring faster time-to-market for new IC products. This predictive capability is crucial in an industry where even minor design flaws can lead to significant setbacks in product development cycles.Another compelling application of AI in IC design is in the realm of automated design synthesis. Traditionally, creating a new IC design involved a labor-intensive process of manually crafting and refining circuit layouts. However, with AI-driven synthesis tools, designers can input high-level design goals and constraints, allowing the algorithms to autonomously generate and optimize circuit architectures that meet specified criteria. This not only reduces the burden on human designers but also opens uppossibilities for exploring innovative design concepts that might have been overlooked using conventional methods.Furthermore, AI plays a pivotal role in enhancing the robustness and reliability of IC designs. Machine learning algorithms can analyze real-time operating conditions and performance data, continuously optimizing parameters to adapt to varying environmental factors or workload demands. This adaptive capability is particularly advantageous in applications such as automotive electronics, where ICs must operate reliably under diverse and often harsh conditions.In addition to design optimization and predictive modeling, AI is also instrumental in the verification and testing phases of IC development. Verification of complex IC designs traditionally required exhaustive simulations and testing scenarios, which are time-consuming and resource-intensive. AI-powered verification tools can automate this process by intelligently generating test cases, detecting potential errors, and even suggesting design improvements based on simulation results.Moreover, the integration of AI in IC design extends beyond the development phase into manufacturing and quality control. AI algorithms can analyze manufacturing data to detect anomalies or deviations from optimal production parameters, thereby improving yield rates and reducing defect rates in semiconductor fabrication.In conclusion, the application of artificial intelligence and machine learning in the integrated circuit design industry represents a paradigm shift, enhancing every stage of the IC design lifecycle from conception to production. By leveraging AI's computational prowess and predictive capabilities, designers can innovate faster, achieve higher performance metrics, and deliver more reliable semiconductor products to meet the demands of today's technology-driven world. As AI continues to evolve, its role in IC design will likely expand, ushering in a new era of efficiency, innovation, and reliability in semiconductor technology.。

收稿日期:2018-11-25 修回日期:2019-03-26 网络出版时间:2019-06-26基金项目:国家自然科学基金(617722770);南京航空航天大学开放基金(kfjj 20171606)作者简介:邓刘梦(1995-),男,硕士研究生,CCF 会员(88983G ),研究方向为软件安全㊁嵌入式系统建模与分析㊁需求可追踪性㊂网络出版地址:http :// /kcms /detail /61.1450.TP.20190626.0829.038.html基于NuSMV 的SysML 模型形式化验证邓刘梦,葛晓瑜,宛伟健(南京航空航天大学计算机科学与技术学院,江苏南京211106)摘　要:航空航天道路交通等高安全领域的系统开发需要保证高安全㊁高可靠,对于该类系统的合理建模以及模型验证则尤为重要㊂当前模型驱动开发方法已经广泛应用于安全关键系统的开发过程中,它支持在早期就对系统进行安全分析和验证,有效地控制开发时间和成本,并降低系统出现风险的可能性㊂但与此同时,需求与设计模型之间仍然存在着沟壑,设计模型是否很好地满足用户所提出的需求在完成系统设计后仍需验证㊂针对系统建模语言缺乏精确形式化语义难以进行模型验证的问题,文中给出一套从SysML 设计模型到NuSMV 模型转换的语义规则,实现了一个自动转换程序,将SysML 模型文件转换成NuSMV 输入文件,进而利用NuSMV 实现SysML 模型的验证㊂最后通过一个铁路控制系统的案例证明了该方法的有效性㊂关键词:需求工程;模型转换;形式化验证;模型驱动开发中图分类号:TP311 文献标识码:A 文章编号:1673-629X (2019)10-0153-04doi:10.3969/j.issn.1673-629X.2019.10.030Formal Verification of SysML Model Based on NuSMVDENG Liu -meng ,GE Xiao -yu ,WAN Wei -jian(School of Computer Science and Technology ,Nanjing University of Aeronautics and Astronautics ,Nanjing 211106,China )Abstract :System development in aerospace road traffic and other high security areas needs to ensure high security and high reliability.It is especially important for the reasonable modeling and model verification of such systems.The model driven development (MDD )method has been widely used in the development of safety -critical systems ,which supports the safety analysis and verification of the system at an early stage ,effectively controlling development time and cost and reducing the possibility of system risk.At the same time ,there is still a gap between the textual requirement and the design model.Whether the design model can well meet the user ’s requirements still needs to be verified after the completion of the system design.Addressing the problem of the lack of precise formal se⁃mantics for the systems modeling language (SysML ),a set of semantic rules for the transformation from SysML design model to NuSMV model is given.An automatic conversion program is implemented to convert the SysML model file into NuSMV input file ,and then to verify the SysML model by NuSMV.In the end ,we prove the effectiveness of this method through the case of railway control system.Key words :requirement engineering ;model transformation ;formal verification ;model driven development0　引　言在过去多年,软件开发面临了多个挑战,新的需求和存在系统不断增长,系统也变得越来越复杂,以至于很难及时地对它们进行构建㊂为了解决这些问题,出现了很多新的方法,其中最突出的一个就是模型驱动开发㊂模型驱动开发代表了一套理论和工业化软件开发的方法框架,在软件开发全生命周期中系统的使用模型作为主要工件,主要是为了解决软件的两个根本危机:复杂性和变更能力㊂但与此同时,模型驱动开发也带来了一些问题:使用自然语言描述的需求与严格定义的模型之间的鸿沟无法很好地连通[1]㊂此外,对于SysML 描述的图形化模型,目前缺乏严格有效的分析和验证方法㊂针对以上存在的问题,文中给出了从SysML 模型到NuSMV 输入模型的转换规则,并实现自动化程序完成这一转换㊂接着利用NuSMV 模型检测的方法来验证SysML 模型的正确性㊂第29卷　第10期2019年10月 计算机技术与发展COMPUTER TECHNOLOGY AND DEVELOPMENT Vol.29　No.10Oct.　20191　SysML系统建模SysML是目前业界常用的系统体系结构建模语言,可用于由软硬件㊁数据和人综合而成的复杂系统的分析与设计㊂然而,为了保证一定的易读性,SysML 采用半形式化的描述方法来定义语义,使用自然语言描述约束和详细语义,力求在形式严格和易于理解间找到平衡[2]㊂在实际中,其图形化的建模方式十分简洁直观,关系链接与约束描述等方式也进一步缩小了模型驱动开发过程中需求描述与模型设计制品间的沟壑㊂但是,其牺牲的部分就是缺乏精确的语义,难以进行严格的语义分析以及正确性验证㊂SysML是一种图形化建模语言,是对象管理组织(object management group,OMG)在对UML2.0的子集进行重用和扩展的基础上提出的一种新建模语言[3]㊂它为软件体系结构建模提供了丰富的图标,涵盖了从系统需求到设计阶段的各项要求,广泛应用于航空航天软件开发过程㊂它致力于建模具有众多组件㊁难以描述㊁理解㊁预测㊁管理㊁设计以及更改的系统,并提供了表达个人需求及其组成的手段,已被学术界和工业界所广为接受,作为一种标准建模语言[4]㊂SysML为系统的结构模型㊁行为模型㊁需求模型和参数模型定义了语义㊂结构模型强调系统的层次以及对象之间的相互连接关系,包括类和装配㊂行为模型强调系统中对象的行为,包括它们的活动㊁交互和状态历史[5]㊂文中主要使用SysML的块定义图对系统的静态结构进行描述,使用状态机图对系统的动态迁移进行描述㊂SysML中,块(block)是系统描述的最小建模单位,可以用来描述每一个单独的组件,同时也是描述系统结构特征和行为特征的单元㊂SysML块以UML类图为基础,并扩展了UML复合结构的一些特征[6]㊂块定义图(block definition diagram)则是用于描述块信息的图㊂它描述了块的属性值㊁块的组成部分㊁块的操作以及对其他块的参考等[7]㊂而状态机图(state machine diagram)则是用来描述系统的状态迁移情况[8]㊂其中状态转移用来描述对象对事件的响应情况㊂关于SysML块定义图以及状态机图的实例将在下一节给出㊂2　NuSMV模型针对SysML模型进行验证,采用NuSMV作为验证工具㊂2.1　输入语言分析NuSMV模型中,系统被描述为模块化的层次结构,支持定义组件的重用[9]㊂其支持的数据类型主要有枚举类型㊁布尔类型和固定数组等㊂基本上,一个完整的NuSMV模型文件主要由两部分组成:系统模型和待验证的系统性质[10-11]㊂NuSMV系统模型部分主要用于描述系统的状态以及状态迁移关系,刻画出系统的静态结构与动态行为[12]㊂通过关键字MODULE来定义模块,通常每一个模块对应一个系统组件[13]㊂通过主模块中的SPEC 字段进行待验证需求性质描述,同时支持计算树逻辑(computation tree logic,CTL)和线性时序逻辑(linear-time temporal,LTL)的表达式[14-15]㊂2.2　SysML模型到NuSMV模型的转换本节根据SysML模型与NuSMV模型的特点[16],给出转化规则,并实现工具完成NuSMV模型实例的自动化生成㊂首先对SysML中的静态图进行转换,文中主要使用的是块定义图㊂规则1:模块名声明㊂描述:对于NuSMV中的模块名根据块定义图中的名称进行命名㊂规则2:静态变量声明㊂描述:对于块定义图中定义的属性都须在相应的模块中通过VAR关键字进行声明㊂规则3:变量初值㊂描述:对于块定义图中所有属性的初值都须在相应的模块中通过ASSIGN关键字进行声明㊂接下来对SysML中的动态行为模型进行转换㊂SysML中主要通过状态机图对系统的状态迁移进行刻画,系统中可能出现的状态迁移,都存在对应的状态机图[12]㊂从另一个侧面来看,状态图也可以理解为对块定义图动态的补充,故在转换中,应将其放入相应的模块中,而不是重新声明模块㊂规则4:状态机图声明㊂描述:对于状态机图转换不重新进行模块声明,将其状态迁移关系通过TRANS㊁next等关键字描述加入到从属的块定义图对应的模块中㊂例如:Car对应的状态机图,其描述的状态迁移关系都应该加入到MODULE car中㊂规则5:状态变量声明㊂描述:如果一个块定义图存在一个对应的状态机图,则应该在此块对应的模块中通过VAR声明一个state变量㊂规则6:状态变量赋值㊂描述:状态机图中state的取值是由去除初始状态和结束状态后所有状态值构成的枚举集合,其初始值应为状态机图中Initial节点指向的第一个状态,通过ASSGIN声明㊂例如:对于汽车car,通过一个状态机图描述其运㊃451㊃ 计算机技术与发展 第29卷行状态可能存在运行或者停止两种状态(见图1),那么MODULE car 中VAR 字段就需加入car _state :{stop ,running }声明,初始状态为stop ,通过ASSGIN init (car _state ):=stop 字段进行声明㊂图1　汽车运行状态机图实例规则7:状态迁移㊂描述:状态机图确定的状态转变使用next 进行描述,并通过case 来表达分支情况㊂例如:car _state 当前状态为stop 下一状态为running 和当前状态为running 下一状态为stop 表示如下:next (car _state ):=casecar _state =stop :{running };car _state =running :{stop };esac规则8:状态迁移条件㊂描述:如果状态机图中的状态迁移存在迁移条件,则需将该守卫条件加入到迁移描述字段中(见图2)㊂例如:在汽车启动前应确定车门是关闭的,否则无法启动㊂next (car _state ):=car _state =stop&door.closed =1:{running };图2　存在守卫条件的状态迁移实例3摇实验与案例分析根据前几节的理论分析,实现了一个SysML 模型到NuSMV 模型自动转换的工具㊂下面通过案例演示㊂案例的场景如下:在铁路控制系统中,在火车通过路口时需要关闭公路两侧的栅栏,保证在火车通过的过程中汽车无法驶入路口,避免发生火车汽车相撞的事故㊂首先通过SysML 建模工具建立该场景的模型如下:图3　铁路案例SysML 块定义图图3中块定义图描述了系统的静态结构信息,图4㊂图4　铁路案例SysML 状态机图在建模分别得到块定义图和状态机图后,利用工具将模型导出为XMI 文件格式以供后续转换使用㊂接着将得到的SysML 模型文件输入到自动转换工具中即可完成转换,得到铁路系统的SMV 文件(见图5)㊂图5　SysML 模型转换工具界面㊃551㊃　第10期 邓刘梦等:基于NuSMV 的SysML 模型形式化验证得到设计模型的实例后,即可利用已有的NuSMV 工具来检测系统需求是否被设计模型所实现㊂首先给出一条安全需求:该系统模型不得出现汽车和火车同时驶入路口的情况,避免事故发生㊂接着在得到的SMV 文件中写入该需求性质LTL 表达式:LTLSPEC G !((Car _state =Car _in )&(Train _state =Train _in ))㊂最后在Windows 10下采用命令行形式运行NuSMV 工具检测该SMV 文件得到的结果如图6所示㊂图6　需求验证结果得到LTL 公式检测结果为false ,即该需求没有被满足㊂NuSMV 工具给出了反例,观察到在1.5状态时同时出现了汽车和火车均进入路口的情况㊂同时表明文中转换工具得到的SMV 文件可以很好地作为NuSMV 工具的输入,证明了该方法的有效性㊂4摇结束语针对SysML 模型缺乏精确语义而难以进行模型正确性验证的问题,给出了一个通过模型转换技术实现模型验证的解决方法㊂实现了一个从SysML 设计模型到NuSMV 模型自动转换的工具,最后利用转换得到的SMV 文件作为模型检测器的输入即可进行SysML 模型的验证㊂参考文献:[1]　刘军霞,熊选东,王松锋.基于随机Petri 网的SysML 状态 机图的验证[J ].计算机应用与软件,2013,30(6):202-208.[2]　夏　宇.基于NuSMV 和STPA 的RBC 交接场景安全分析方法研究[D ].北京:北京交通大学,2018.[3]　SALMAN Y D ,HASHIM N L.Automatic test case genera⁃tion from UML state chart diagram :a survey [M ]//Ad⁃vanced computer and communication engineering technology [s.l.]:Springer International Publishing ,2016:123-134.[4]　FRIEDENTHAL S ,MOORE A ,STEINER R.A practicalguide to sysML [M ].[s.l.]:[s.n.],2011:41-46.[5]　曹德建,黄志球,阚双龙,等.基于故障扩展SysML 活动图的软件安全性分析方法研究[J ].小型微型计算机系统,2015,36(9):2067-2074.[6]　王　栋.基于SysML 的武器装备体系结构建模与仿真方法研究[D ].长沙:国防科学技术大学,2009.[7]　NEJATI S ,SABETZADEH M ,ARORA C ,et al.Automatedchange impact analysis between SysML models of require⁃ments and design [C ]//Proceedings of the 24th international symposium on foundations of software engineering.Seattle ,WA ,USA :ACM ,2016:242-253.[8]　ANDRADE E ,MACIEL P ,CALLOU G ,et al.A methodolo⁃gy for mapping SysML activity diagram to time petri net for requirement validation of embedded real -time systems with energy constraints [C ]//International conference on digital society.Cancun ,Mexico :IEEE ,2009:266-271.[9]　CIMATTI A ,CLARKE E ,GIUNCHIGLIA F ,et al.NUS⁃MV :a new symbolic model checker [J ].International Journal on Software Tools for Technology Transfer ,2000,2(4):410-425.[10]ARCAINI P ,GARGANTINI A ,RICCOBENE E.Asmeta⁃SMV :a way to link high -level ASM models to low -level NuSMV specifications [C ]//Proceedings of the second inter⁃national conference on abstract state machines ,alloy ,B and Z.Orford ,QC ,Canada :Springer -Verlag ,2010:61-74.[11]陈冬火,刘　全.基于符号执行和LTL 公式重写的测试用例产生方法[J ].计算机研究与发展,2013,50(12):2661-2675.[12]周玉平.基于UML -NuSMV 模型的列控系统需求阶段的安全分析[D ].北京:北京交通大学,2015.[13]何　洋,洪　玫,祁琳莹,等.基于模型检测工具NuSMV的功能测试用例生成方法[J ].计算机应用,2015,26(z 2):155-159.[14]王　曦,徐中伟,梅　萌.基于模型检测的软件安全性验证方法[J ].武汉大学学报:理学版,2010,56(2):156-160.[15]KAN Shuanglong ,HUANG Zhiqiu.Detecting safety -relatedcomponents in statecharts through traceability and model sli⁃cing [J ].Software :Practice and Experience ,2017,48(2):428-448.[16]俞晓锋,王立松.SysML 状态图合理性验证研究与实现[J ].电子科技,2014,27(5):127-131.㊃651㊃ 计算机技术与发展 第29卷。

Embedded Software—Technologies andTrendsXu ShuangSoftware Engineering College, Sichuan University,Chengdu, ChinaE-mail:xsqnzl@Abstract—Our world and society are shaped and governed by embedded systems. That most microprocessors are in systems for cars, mobile communication, washing machines, aircraft, robots, traffic management, cameras, and audio equipment trend toward embedded software in practically all systems is accelerating.Keywords- embedded software; software; technologies; trends;I. IntroductionEmbedded systems are microcontroller based systems built into technical equipment. They’re designed for a dedicated purpose and usually don’t allow different applications to be loaded and new peripherals to be connected. Communication with the outside world occurs via sensors and actuators; if applicable, embedded systems provide a human interface for dedicated actions. The software executed in those systems is called embedded software. It’s an integral part of the system itself. Embedded software is defined as a special-purpose software system built into a larger system. The end user usually doesn’t recognize embedded software as software in the traditional way; instead, he or she perceives it as a set of functions that the system provides. Embedded software is a key driver of most industries.In this introduction to the special issue, we provide a snapshot of the topic of embedded software. We will show similarities to general purpose I T and highlight embedded systems’peculiarities. This introduction isn’t a tutorial on all facets of engineering and maintaining embedded software; rather, it highlights trends and topics worth thinking about. Above all, it relates hands-on experiences from industry projects from which all of us can learn, independent of which type of software and domain we deal with in our day-to-day engineering work.II. The ProblemToo often, when speaking about software, we concentrate on IT systems; we think about general-purpose PCs, big IT systems, and online Internet applications. However, such IT systems incorporate less than 2 percent of the microprocessors produced. Most microprocessors are in systems for cars, mobile communication, washing machines, aircraft, robots, traffic management, cameras, and audio equipment. This trend toward embedded software in practically all systems is accelerating. The world market for embedded systems is approximately 160 billion euros, involving approximately 3 billion embedded units delivered per year and a compound annual growth of 9 percent.1–3 Owing to the nature of embedded systems, most of these sales are on the hardware side; However, the relevance of software and services is rapidly increasing.Cars today have 100 Mbytes of software running, with a complexity growing more quickly than that of IT systems such as those of SAP, Oracle, and Microsoft. The same holds for pacemakers and satellites, starting from a smaller size, of course. To highlight embedded software’s ubiquity, Figure 1 shows the size and annual distribution volume of selected embedded software.4 Although these figures are comparable to those for the world’s biggest software packages, such as Microsoft Windows, embedded software’s complexityis larger by far owing to real-time and interface constraints that IT, application, and desktop software don’t face.You could argue that software is software is software. This is true on the microscopic level. But embedded systems involve many challenges that transcend the ordinary requirements for application and enterprise-style IT systems. These challenges fall into the following six main categories.Real TimeEmbedded software is by definition part of a larger system, such as a technical process, the human body, or an industrial automation system. These systems all pose external constraints that must be addressed in real time. The embedded system’s timing must provide the expected action within a maximum specified time under all circumstances.ReliabilityUnexpected behavior from an embedded system might seriously damage its environment. Often, such software must operate for decades without service; there’s no possibility for upgrades and service patches. End users demand deterministic long term behaviors from these systems.SafetyMuch embedded software one way or another impacts people and thus potentially poses a safety hazard. Safety has become a key requirement, specifically as mechanical backups are for cost reasons disappearing in systems such as airplanes, cars, or industrial plants. The entire life cycle thus is governed by standards that demand systematic processes,state-of-the-practice technologies, and continually educated engineers.SecurityCurrent embedded systems are highly interconnected to each other and to sensors, actuators, and interfaces. In many embedded systems, security directly means safety. A car contains approximately 30 to 70 embedded systems that communicate with each other across a variety of standardized bus systems. Embedded security is crucial to avoid life threatening situations. The “Internet of things” will work to our advantage only if we reliably ensure security —much more than in current IT systems.Limited ResourcesEmbedded software is constrained by small memory space and limited data-processing capabilities, low-cost microcontrollers, stringent regulations with respect to “green”behaviors, and low power consumption. For instance, implanted medical devices must operate for years without battery replacement, and mobile phones must work for hours on sub watt batteries. HeterogeneityOwing to embedded software’s long lifetime, it must conform to a wide range of changes in its environment. Processors, sensors, and hardware parts change over time, whereas the software remains almost the same. In addition, the software requires portability, autonomy, flexibility, and adaptability. “Design-for-x” is thus a key paradigm to cope with multiple conflicting requirements.III. MethodsWe can learn much from embedded software engineering. Too often, software development is still based on the paradigm that software can be rather easily repaired and changed after release. This has led to the bizarre situation where we’re used to software being faulty by definition—a situation that for any other product simply isn’t imaginable. However, this isn’t the case with embedded software; nobody would download a patch for his or her pacemaker from the Internet. Independent of our own software application domains, we should learn from the embedded world in terms of engineering approaches, systematic processes, and the strong focus on quality demands from a variety of operational scenarios and environmental conditions.The articles in this issue highlight relevant current technologies and approaches but also emerging trends in embedded system development. “Trendsin Embedded Software Engineering,” by PeterLiggesmeyer and Mario Trapp, summarizes current advances in embedded software engineering. You could argue that “regular”IT and application software development have long used some of the described techniques. True and not so true, as our Point/Counterpoint authors Les Hatton and Michiel van Genuchten highlight with interesting insights.One of the most relevant is toward more abstraction and thus being able to better manage complexity throughout the life cycle. This trend began some years ago, when C replaced assembly language. It might sound odd, but performance issues, memory space, and the need for deterministic behaviors still mandate C and assembly language, which are the primary languages in over 80 percent of embedded systems. In the near future, embedded system developers will use model-driven development (MDD) to work at different abstraction levels. “UML-Based Model-Driven Development for HSDPA [High-Speed Downlink Packet Access] Design,” by Jesús Martinez and his colleagues, shows how they introduced MDD to embedded software development. The application and development of domain-specific languages is well suited for the embedded domain as well. This approach can easily take into account the embedded domain’s hardware constraints.The trends to add more and more functions into an embedded system but to consume as little power as possible are contradictory. One possiblesolution for this dilemma involves multi-core microcontrollers, which are entering the embedded domain just about now. This raises two questions: how do you deal with the complexity of developing software for multi-core microcontrollers, and how do you best introduce parallel programming? “Embedded MultiprocessorSystems-on-Chip Programming,” byJean-Yves Mignolet and Roel Wuyts, sheds light on these questions and might help professionals avoid common traps when entering this domain.Owing to embedded software’s c lose association with critical environments and often life threatening risks, it faces high quality requirements. Systematic, thorough, and completely traceable verification and validation is key to good quality. In “Formal Modeling and Verification of Safety- Critical Software,”Junbeom Yoo and his colleagues show how they applied such techniques to safety-critical software in a nuclear reactor protection system. In the Software Technology department article, “Ensuring the Integrity of Embedded Software with Static Code Analysis,”Ben Chelf and Christ of Ebert second this need for systematic verification and introduce static code analysis and current related practices and tools for embedded software.High quality and performance requirements combined with fierce cost pressures demand strong engineering and management processes that continuously improve. In “A More Agile Approach to Embedded Systems Development,”Michael Smith and his colleagues show how to keep good processes sufficiently lean to allow for flexibility and efficiency. Finally, in “Experiences in Improving Flight Software Development Processes,”Ronald Kirk Kandt emphasizes the impact of a higher level of software development maturity on software engineering activities. He underlines that without good processes, we won’t be able to meet embedded software’s many challenging requirements.The reason our planet can bear over six billion people is embedded software. Because software is so ubiquitous and embedded in nearly everything we do, we need to stay in control. We must ensure that the systems and their software run as we intend—or better. Staying in control means knowing w hat’s going on and knowing the limits of what we’re doing. This is relevant for all software engineering but is critical for embedded software. If embedded software has insufficient quality, serious damage will occur, whether injuries, deaths,or catastrophes.For us to cope with these truly embedded challenges, awareness of embedded software and its impacts must improve across society. Here are a few recommendations that each of us can pursue in our own environments.Understand Impacts and PotentialsPolicy makers tend to overlook embedded systems’ perspectives and challenges because those systems don’t get much media coverage. We must educate them on the challenges and risks and convincethem to allocate funding to improve the scientific basis and its application. A good understanding in due time mitigates the risk of accidents and thus negative impacts on our society.Provide Hands-On EducationEducation tends to emphasize theoretical concepts and overly small classroom examples. Embedded education must cover computer science as well as electrical engineering and systems engineering. Educators must confront engineering students with real-world challenges and thus ingrain a true engineering spirit of solving complex problems.Look to the Entire Life CycleResearch today is fragmented and divided into technology, application, and process domains. It must provide a consistent,systems-driven framework for systematic modeling, analysis, development, test, and maintenance of embedded software in line with embedded systems engineering.Invest into AbstractionIndustry tends to incrementally evolve existing proprietary approaches bottom-up. So, complexity and cost grow, whereas quality at best stagnates over time. Standardization, shareable models, open interfaces, and top-down verifiability are necessary to better control complexity and thus ensure high quality from concept to maintenance.IV. ConclusionsEmbedded software not only increases the variability, configurability, extendibility, and changeability of everyday products but also allows for a greater variety of functions. In the future, embedded software will be in everything—your automated home, your intelligent automobile, communication infrastructures, medical instruments and implants, and ubiquitous control systems. We’ll see new energy-related technologies that increase the efficiency of electrical current transmission and provide immediate, effective ways to address energy and climate demands. We’ll see embedded systemsno longer being defined by the computing hardware they use. Rather, they’ll be designed to do any function to achieve multiple and changing objectives, whether on a microcontroller, a microprocessor, a signal processor, a biological assembly, or any other programmable logic device.The more quality of life we desire, the higher living standards we want to establish across the planet, and the more we demand security and safety, the more we need embedded software. Our task is to evolve embedded software engineering to master these grand challenges.。

基于混成自动机的矿井机车无人驾驶系统模型卫星;王军【摘要】The composite character of simultaneous existence of sequence and discreteness is shown in the unmanned driving system of mine locomotive.The system evolution can be depicted accurately by hybrid automaton.The modeling and verification of the system is researched.Firstly, the driving process model with time evolution is set which follows the principle of safe and efficient driving.Then the state events of each turnout signals that affect the system evolution are defined.The recursive algorithm of conversion time of the system under the different types of events is given.And the hybrid automaton model of the system can be obtained.Finally, the accuracy and completeness of the model are verified by the numerical results in various situations.%矿井机车无人驾驶系统显著表现出连续和离散同时存在的混成特征,混成自动机能够精确刻画其系统演化过程,文章研究该系统的建模及验证问题.首先设定遵循安全高效驾驶原则的时间演化行驶过程模型;然后定义影响系统演化的各道岔信号灯状态事件,并给出不同类型事件下的系统状态转换时刻递推算法,从而得到系统混成自动机模型;最后以多种场景下的数值结果验证了模型的正确性与完备性.【期刊名称】《合肥工业大学学报（自然科学版）》【年(卷),期】2017(040)008【总页数】6页(P1042-1047)【关键词】混成自动机;矿井机车;无人驾驶;混成系统;系统建模【作者】卫星;王军【作者单位】合肥工业大学计算机与信息学院,安徽合肥 230009;合肥工业大学计算机与信息学院,安徽合肥 230009【正文语种】中文【中图分类】TP399混成系统是实时嵌入式系统的一种重要子类,其行为中广泛存在离散控制逻辑跳转与连续实时行为交织混杂的情况[1]。

文章编号：1673-0291（2023）02-0001-12DOI ：10.11860/j.issn.1673-0291.20220154第 47 卷 第 2 期2023 年 4 月Vol .47 N o .2Apr. 2023北京交通大学学报JOURNAL OF BEIJING JIAOTONG UNIVERSITYCTCS -1级列控系统无线广播通信场景建模与验证刘中田 1， 张茜 2， 赵焕 1（1.北京交通大学 电子信息工程学院，北京 100044；2.北京和利时系统工程有限公司，北京 100176）摘要：在高铁线路故障情况下，为了支持高铁动车组在普速线路上运行，国铁集团组织研究了高铁动车组利用普速线迂回运行系统.该系统车地间无线通信拟采用的无线单向广播方案，在现有的列控系统中从未使用过，对其进行建模与验证研究具有重要意义.通过分析CTCS -1级列控系统的总体技术规范，对无线广播通信场景进行详细设计和完善，采用SysML 语言对场景建模，通过设计SysML -PRISM 模型的转换规则将场景的SysML 模型转换为概率模型，得到由信道模块、车站数据服务器（Station Data Server ， SDS ）模块、列车模块构成的无线广播通信场景概率模型，采用概率模型检验工具PRISM 对场景的概率模型进行描述和验证.结果表明：场景设计合理、无线单向广播通信方式可行、SDS 规定的优先发送报文的次数应该为2次或3次.本文中对无线广播通信场景的研究能提早发现系统技术方案中可能存在的问题，为相关研究提供参考.关键词：列控系统；无线广播通信场景；概率模型检验；SysML ；车站数据服务器中图分类号：U238.2；TP301 文献标志码：AModeling and verification of radio broadcast communication scenariofor CTCS -1 train control systemLIU Zhongtian 1, ZHANG Xi 2, ZHAO Huan 1（1.School of Electronic and Information Engineering, Beijing Jiaotong University, Beijing 100044, China ； 2.BeijngHollySys Co., Ltd., Beijing 100176, China ）Abstract :In order to support the operation of high -speed EMUs on common speed line after the fault of high -speed railway line, China Railway Group has organized and studied the circuitous operation system of high -speed railway EMUs using the common speed line. Radio one -way broadcasting method is used in the communication between the train and the ground of the system, which has never been used in the existing train control system before, so it is of great significance to model and analyze it. By analyzing the overall technical specification of CTCS -1 train control system, the radio broadcast communication scenario is designed and improved in detail. The scenario is modeled by SysML lan⁃guage, the SysML model is transformed into probability model through the designed conversion rule of SysML -PRISM model. Finally, the probability model of radio broadcast communication scenario composed of channel module, Station Data Server (SDS) module and train module is obtained. The probabilistic model checking tool PRISM is used to describe and verify the probability model of the收稿日期：2022-11-11；修回日期：2023-01-27基金项目：国家自然科学基金（52272328）Foundation item : National Natural Science Foundation of China （52272328）第一作者：刘中田（1979—），男，安徽蚌埠人，副教授，博士.研究方向为列控系统建模、可靠性、安全性研究.email ：***************.cn.引用格式：刘中田，张茜，赵焕.CTCS -1级列控系统无线广播通信场景建模与验证［J ］.北京交通大学学报，2023，47（2）：1-12.LIU Zhongtian ，ZHANG Xi ，ZHAO Huan.Modeling and verification of radio broadcast communication scenario for CTCS -1 train control system ［J ］.Journal of Beijing Jiaotong University ，2023，47（2）：1-12.（in Chinese ）北京交通大学学报第 47 卷scenario. The results indicate that the rationality of the scenario design, the feasibility of radio one-way broadcast communication, and the number of preferentially sending telegrams specified by SDS should be 2 or 3 times. The research of radio broadcast communication scenario can find the possible problems in the system technical scheme in advance and provide referencs for related research units.Keywords:train control system；radio broadcast communication scenario；probabilistic model check⁃ing； SysML； station data serverCTCS-0级列控系统的构成包括列车运行监控装置（Train Operation Monitoring Device，LKJ）及通用机车信号，LKJ在一些情况下具有安全隐患，如线路数据发生变化、机车长交路大面积运用、机车调配较频繁等情况［1-2］.目前装备CTCS-3级列控系统的高速动车组仅能运行在高速铁路上，不具备在普速线路运行的条件，当高速铁路某段线路发生故障后，如果动车组能够通过普速线路来绕过故障段，那么运输效率能够得到提升.基于以上两点原因，2020年，中国铁路总公司组织相关单位研究了C3高铁动车组利用普速线迂回运行系统（简称CTCS-1级列控系统）的总体技术方案，该系统在尽量减少对普速线路上既有设备改造的前提下，把普速线改造成CTCS-1级列控系统，不仅解决了CTCS-0级列控系统存在的安全相关问题，而且支持动车组在普速线路上运行.新提出的CTCS-1级列控系统的技术方案目前尚不成熟［3-4］，在当前的系统总体技术方案中，车地之间的通信采用基于400 MHz的无线单向广播通信方式，与现有的列控系统的车地通信方式有明显的差别，这种单向广播通信方式提高了列控数据传输的时效性和准确性，并且大大降低了运行成本和施工难度.对无线广播通信方式进行研究能提前发现系统技术方案中可能存在的问题.目前，对列控系统车地通信的研究主要集中在GSM-R（GSM for Railway）无线通信系统.赵会兵等［5］采用基于SimEvents和Stateflow的方法对C3车地无线通信系统建模，得到建立安全连接时间、无线应用消息传输延迟时间.徐田华等［6］采用CPN研究ETCS无线通信系统，仿真得到数据帧延迟时间概率分布.全宏宇等［7］利用概率模型检验工具PRISM建立C3无线通信系统的概率模型，得到系统的稳态概率、列车运行速度对无线通信可靠性的影响.Jansen等［8］采用StoCHARTS研究ETCS（Eu⁃rope Train Control System）无线通信系统，得到确定时间延迟下，信道可靠的概率.谢雨飞等［9］利用交互式马尔可夫链研究CTCS无线通信系统，结合模型检验算法，分析无线通信的可靠性.然而，以上的研究主要针对GSM-R无线通信系统，未涉及到对基于400 MHz无线单向广播通信方式的研究.本文根据CTCS-1级列控系统总体技术规范，对无线广播通信场景进行设计和完善，采用SysML 和PRISM相结合的方法对无线广播通信场景进行研究.首先建立了无线广播通信场景SysML模型，并通过设计SysML-PRISM模型的转换规则将场景的SysML模型转换为概率模型，最后采用概率模型检验工具PRISM对场景的概率模型进行验证分析，验证了无线广播通信场景设计的合理性，确定了无线通信参数，对CTCS-1级列控系统技术方案后续研究工作具有重要参考价值.1无线广播通信场景设计1.1CTCS-1级列控系统简介CTCS-1级列控系统由车载设备、地面设备组成，其结构图如图1所示.车载设备包括：主控单元、无线通信单元、轨道电路信息接收单元、应答器信息接收单元、数据记录单元、列车接口单元、人机界面、测速测距单元等.地面设备包括：车站数据服务器（Station Data Server， SDS）、联锁（Computer-Based Interlockin，CBI）、临时限速服务器（Temporary Speed Restriction Server，TSRS）、闭塞、轨道电路、应答器、400 MHz无线通信设备等.地面的核心设备是SDS，其根据自身存储的车站线路信息、从CBI 获得的进路信息、从TSRS获得的临时限速信息，生成无线报文，采用无线单向广播通信方式发送给列车，车载设备把无线报文、轨道电路码序相结合，生成监控列车运行的目标距离速度控制曲线［10］.1.2无线广播通信场景设计在CTCS-1级列控系统总体技术规范文档中，对无线广播通信场景的描述很少，缺少场景的详细细描述和设计.依据CTCS-1级列控系统的结构、功能以及技术规范，对无线广播通信场景进行设计，如图2所示.设定在图2所示的线路上有3列车运行，列车1办理正线发车进路，列车2办理侧线接车进路，列车3办理侧线通过进路.3列车在运行过程中车地之间的通信过程如下：1）车站未办理任何进路时，SDS从存储的线2刘中田等：CTCS-1级列控系统无线广播通信场景建模与验证第 2 期路数据中获取进站口处BYS、BS、BYX、BX共4个应答器的无进路状态的报文，以及出站口处BXF、BYXF、BSF、BYSF共4个应答器的报文.在无进路情况下SDS通过轮询方式广播无线报文的顺序为：应答器BYS报文、应答器BS报文、应答器BYX报文、应答器BX报文、应答器BXF报文、应答器BYXF报文、应答器BSF报文、应答器BYSF报文.2）随后，车站办理了列车1的下行正向正线发车进路，SDS根据联锁提供的正线发车进路信息和区间方向信息，结合线路数据和临时限速信息，SDS 生成针对应答器BXI、BSI的无线报文.然后，车站办理了列车2的下行正向侧线接车进路，SDS根据联锁提供的侧线接车进路信息和区间方向信息，结合线路数据和临时限速信息，SDS生成针对应答器图 1　CTCS-1级列控系统结构XⅠG列车3列车1图 2　无线广播通信场景设计的示意图Fig.2　Schematic diagram of radio broadcast communication scenario design3北京交通大学学报第 47 卷BYX、BX的无线报文.最后，车站办理了列车3的上行正向侧线通过进路，SDS根据联锁提供的侧线通过进路信息和区间方向信息，结合线路数据和临时限速信息，SDS生成针对应答器BYS、BS、BX4、BS4的无线报文.3）由于车站为上述3列车办理了进路，SDS应优先发送这3条进路对应的应答器的报文.在该情况下SDS以轮询方式向3列车广播无线报文的顺序变为：应答器BXI报文、应答器BSI报文、应答器BYX报文、应答器BX报文、应答器BYS报文、应答器BS报文、应答器BX4报文、应答器BS4报文、应答器BXF报文、应答器BYXF报文、应答器BSF报文、应答器BYSF报文.SDS每500 ms发送一条应答器报文.4）3列车运行过程中，每列车的车载设备实时接收SDS发送的所有应答器报文，并将接收到的报文存储在车载设备中.5）当列车1运行至应答器BSI时，车载设备从已经接收到的报文中根据应答器编号选取并使用应答器BSI的报文；当列车1运行至应答器BXI时，车载设备从已经接收到的报文中根据应答器编号选取并使用应答器BXI的报文；依据应答器报文提供的线路参数信息生成目标距离模式曲线，监控列车1完成正线发车.6）当列车2分别运行至应答器BYX、BX时，车载设备从已经接收到的报文中分别选取并使用相应应答器的报文，然后依据应答器报文提供的线路参数信息生成目标距离模式曲线，监控列车2完成侧线接车.7）当列车3分别运行至应答器BYS、BS、BX4、BS4时，车载设备从已经接收到的报文中分别选取并使用相应应答器的报文，然后依据应答器报文提供的线路参数信息生成目标距离模式曲线，监控列车3完成侧线通过.2基于SysML和PRISM的建模验证本文提出基于SysML和PRISM的建模与验证方法，避免直接使用概率模型检验方法进行建模，降低了概率模型检验方法的使用难度，同时为SysML 模型的形式化验证和分析提供参考.首先采用SysML建模语言对场景进行建模，为场景验证提供基础模型.其次设计SysML模型-PRISM模型的转换规则，从而得到场景的PRISM模型，并采用概率模型检验工具PRISM进行验证［11-12］.2.1概率模型检验工具PRISMPRISM是一种开源的概率模型检验工具，可以对具有随机特性或概率行为的系统进行建模分析［13］.如分析系统在4 h后的失效概率，30 min后消息队列的预期大小等.PRISM检验的框架如图3所示［14-15］.从图3中可以看出，概率模型检验工具PRISM有两个输入：1）用PRISM描述的系统概率模型，PRISM支持的概率模型有：连续时间马尔可夫链（Continous-Times Markov Chain， CTMC）、离散时间马尔可夫链（Dis⁃crete Time Markov Chain， DTMC）、概率时间自动机（Probabilistic Timed Automata， PTA）、马尔可夫决策过程（Markov Decisim Praess， MDP）等［16-17］；2）用概率时序逻辑描述的系统属性，PRISM中用概率计算树逻辑（Probabilistic Computational Tree Logic，PCTL）来刻画DTMC、MDP、PTA模型的属性规范，用连续时间随机逻辑（Stochastu Logic， CSL）来刻画CTMC 模型的属性规范［18］用PRISM描述系统的概率模型时，最重要的部分是模块、变量.每个模块的格式为：module name...endmodule每个模块的定义包含变量和命令两部分.变量描述了模块可以处于的状态，命令描述了状态随时间变化的行为，命令的格式如下：［action］guard -> prob_1 ：update_1 + … + prob_n ： update_n；其中如果条件（guard）为真，模块的变量将按照相应的概率进行更新.用PRISM完成对系统的概率模型的描述之后，需要用概率时序逻辑描述模型待分析的性质. PRISM的概率时序逻辑中最重要的运算符是P运算符和S运算符.其中P运算符用来推理事件发生的概率，适用于PRISM支持的所有概率模型.P运算符的格式为：P bound ［pathprop］，其在模型的状态s中为真，表示“来自状态s的路径满足路径属性pathprop的概率满足边界bound”.S运算符用来推理模型的稳态行为，即模型在长期或均衡中的行为，适用于PRISM支持的DTMC和CTMC模型.S运算符的格式为：S bound ［prop］，其在模型的状态s中图 3　PRISM检验框架Fig.3　Structure of PRISM checker4刘中田等：CTCS-1级列控系统无线广播通信场景建模与验证第 2 期为真，表示“从s开始，处于满足PRISM 属性 prop 的状态的稳态（长期）概率满足边界bound”.用概率时序逻辑完成对模型待分析性质的描述之后，在PRISM中进行验证，进而得到验证结果.2.2SysML模型到PRISM模型的转换规则建立SysML活动图到PRISM模型的转换规则，具体的转换过程如下：1）SysML活动图简化.复杂SysML活动图包含顶层活动图、活动子图，需要将其分解为多个仅包含基本元素的标准化活动图［19］.2）标准化活动图转换.以一个标准化活动图的转换为例，首先识别出该标准化SysML活动图中的所有基本元素，其次把每个基本元素转换为概率模型，活动图中若未标记概率则默认为条件满足时活动发生概率为1，最后用PRISM语言描述转换后的概率模型.把所有基本元素转换后的概率模型组合在一起得到整个SysML活动图转换后的概率模型，用PRISM语言对其进行描述，最终完成该标准化活动图到PRISM模型的转换.SysML活动图中的每个基本元素转换为PRISM模型的规则［20-22］如表1所示.规则1：初始节点的转换.初始节点标志着活动图的起点，其标识法是一个小的实心圆形，一般仅有一条输出边.在表1中，活动由初始节点开始后到达活动A，首先把其转换为概率模型，再把概率模型用PRISM语言描述.规则2：动作节点的转换.动作节点是活动图的基本节点，描述创建、调用、销毁一个对象的方法，用圆角矩形表示.表1中描述了存在一个输入转移A 和一个输出转移B的动作节点的转换过程.规则3：活动最终节点的转换.活动最终节点标记整个活动图的结束，其标识法是包含小的实心圆形的圆形，在一个活动图中可以添加多个活动最终节点.规则4：分支节点的转换.分支节点代表活动中并发序列的开始，其标识法是具有一条输入边、多条输出边的线段，令牌到达分支节点后提供给所有的输出边.规则5：流最终节点的转换.流最终节点代表单个控制流的结束.其标识法是包含×的圆形，令牌到达流最终节点后会被销毁.规则6：集合节点的转换.集合节点代表并发序列的结束，其标识法是具有多条输入边、一条输出边的线段.规则7：决定节点的转换.决定节点代表可选序列的开始，其标识法是具有一条输入边、多条输出边的菱形.在表1中，决定节点有两条输出边.规则8：合并节点的转换.合并节点代表可选序列的结束，其标识法是具有多条输入边、一条输出边的空心菱形.表 1　活动图中的基本元素的转换规则Tab.1　T ransformation rules for basic elements in activity diagram初始节点的转换动作节点的转换活动最终节点的转换分支节点的转换Initial: bool init trueA: [0. . M] init 0;[Initial]Initial & A<M->(Initial'=false) & (A'=A+1);A: [0. . M] init M;B: [0. . M] init 0;A>0 & B<M->(A'=A-1) & (B'=B+1);A: [0. . M] init M;Final: bool init false;[A]A>0 &! Final->(A'=A-1)&(Final'=true);A: [0. . M] init M;B: [0. . M] init 0;C: [0. . M] init 0;[A]A>0 & B<M & C<M-> (A'=A-1) & (B'=B+1) & (C'=C+1);规则SysML活动图片段活动图转换后的概率模型用PRISM语言描述的概率模型5北京交通大学学报第 47 卷流最终节点的转换集合节点的转换决定节点的转换合并节点的转换A: [0. . M] init M;FlowFinal: [0. . M] init 0;[A]A>0 & FlowFinal<M->(A'=A-1) & (FlowFinal'= FlowFinal +1);formula Join = Join_pin1>0 & Join_pin2>0;formula Join=Join_pin1>0 & Join_pin2>0;A: [0. . M] init M;B: [0. . M] init M;Join_pin1: [0. . M] init 0;Join_pin2: [0. . M] init 0;C: [0. . M] init 0;[A]A>0 & Join_pin1<M->(A'=A-1) & (Join_pin1'= Join_pin1 +1);[A]B>0 & Join_pin2<M->(B'=B-1) & (Join_pin2'= Join_pin2 +1);Join & C<M-> (Join_pin1'= Join_pin1 -1)& (Join_pin2'= Join_pin2 -1) & (C'=C+1);A: [0. . M] init M;B: [0. . M] init 0;C: [0. . M] init 0;[A]A>0 & B<M & C<M->p:(A'=A-1) & (B'=B+1)+(1-p): (A'=A-1) & (C'=C+1);A: [0. . M] init M;B: [0. . M] init M;C: [0. . M] init 0;[A]A>0 & C<M & C<M-> (C'=C+1) &(A'=A-1);[B]B>0 & C<M & C<M-> (C'=C+1) &(B'=B-1);续表规则SysML活动图片段活动图转换后的概率模型用PRISM语言描述的概率模型3无线广播通信场景建模与验证3.1无线广播通信场景SysML模型根据1.2节中设计的无线广播通信场景，使用EA软件建立无线广播通信场景的活动图.活动图表示随着时间的推移，行为和事件的发生序列，可以通过行为来表示事件、数据或能量的流动［23］.无线广播通信场景的活动图如图4和图5所示.在1.2节中设计的3列车的车地通信流程的基础上，图4中的活动图描述了车站数据服务器向列车车载设备发送无线报文的过程.当车站数据服务器向列车发送无线报文时，考虑到无线通信信道是否故障以及其他因素的影响，假设信道正常时，车站数据服务器成功向列车发送报文，信道故障时，车站数据服务器向列车发送报文失败.同时车站数据服务器以500 ms为周期向列车广播无线报文，即车站数据服务器每500 ms发送一条应答器报文.图4中用到了等待时间动作，启动等待时间动作后，开始计时，500 ms后，执行过程会进入下一个节点.图5中的活动图描述了3列车接收车站数据服务器发送的无线报文的过程.办理进路后，列车运行至应答器，如果车站数据服务器发送报文成功，列车接收到该应答器报文，如果车站数据服务器发送报文失败，则列车接收不到该应答器报文.3.2无线广播通信场景概率模型DTMC模型的数学定义为：D=（S，s_0，P，L），其中S为模型所有的有限状态；s_0∈S表示模型的初始状态；P：S×S→［0，1］为概率转移矩阵；L：S→6刘中田等：CTCS-1级列控系统无线广播通信场景建模与验证第 2 期2^AP表示一系列来自原子命题的功能标签.SDS 向列车发送无线报文时，如果从CBI、TSRS获取的进路信息或者临时限速信息发生变化时，要优先选择该进路的无线报文发送，SDS根据配置信息选择图 4　SDS发送无线报文的活动图Fig.4　Activity diagram of SDS sending radio messages7北京交通大学学报第 47 卷优先发送机制，将需要优先发送的报文在发送队列中优先发送2~6次.如果SDS将需要优先发送的报文发送的次数过多，会导致车站中的某些列车不能及时接收到其进路上的应答器的报文，进而影响该列车的运行.因此，SDS的优先发送机制中规定的优先发送报文的次数取2~6之间的任意整数是否合理有待验证.按照2.2节中提出的SysML模型转换为PRISM模型的规则，把无线广播通信场景的活动图转换为适用于概率模型检验工具PRISM进行验证的概率模型.将SDS发送无线报文的活动图映射为概率模型中的SDS模块，将3列车接收并选用无线报文的活动图映射为概率模型中的列车模块，在此基础上，在概率模型中添加信道模块，信道模块用来描述无线通信信道的随机特征.在无线广播通信场景的概率模型中添加的信道模块如图6所示，信道模块一共有3个状态，chan⁃nel0代表信道空闲，channel1代表信道占用，chan⁃nel2代表信道故障.当无线通信信道空闲时，以概率P1进入到信道占用状态，以概率1-P1进入到信道故障状态.当信道占用时，以概率1进入信道空闲状态.当信道故障时，以概率0.98进入信道空闲状态，以概率0.02返回到信道故障状态.无线广播通信场景的概率模型中的SDS模块是由3.1节中建立的SDS发送无线报文的活动图转换得到的.按照提出的SysML-PRISM模型的转换规则，考虑通信过程中的误码问题，在转换后的概率模型上增加误码率Pe得到SDS模块，如图7所示. SDS模块一共有4个状态，SDS0表示SDS处于无连接状态，SDS1表示SDS处于开始发送某个应答器的图 5　列车接收并选用无线报文的活动图Fig.5　Activity diagram of the three trains receiving and selecting radio messages 8刘中田等：CTCS -1级列控系统无线广播通信场景建模与验证第 2 期报文的状态，SDS 2表示SDS 处于成功发送该应答器的报文的状态，SDS 3表示SDS 发送该应答器的报文失败的状态.当SDS 处于状态SDS 0时，以概率1转移到状态SDS 1.当SDS 处于状态SDS 1时，如果满足条件①，那么以概率1−Pe 转移到状态SDS 2，以概率Pe 转移到状态SDS 3.当SDS 处于状态SDS 1时，如果满足条件②，那么以概率1转移到状态SDS 3.当SDS 处于状态SDS 2或者状态SDS 3时，如果满足条件③，那么以概率1转移到状态SDS 1；如果满足条件④，那么以概率1转移到状态SDS 0.无线广播通信场景的概率模型中的列车模块是由3.1节中建立的3列车接收并选用无线报文的活动图转换得到的.按照提出的SysML -PRISM 模型的转换规则，转换后的列车模块如图8所示. 信道模块、SDS 模块、列车模块中状态转移条件和变量的含义如表2和表3所示.Train10表示列车1处于无连接状态，Train11表示列车1处于接收SDS 发送的应答器报文的状态，Train12表示列车1处于到达应答器BSI 时已经收到该应答器报文的状态，Train13表示列车1处于到达应答器BSI 时未收到该应答器报文的状态.当列车1处于状态Train10时，以概率1转移到状态Train11.当列车1处于状态Train11时，如果满足条件⑤，那么以概率1转移到状态Train12；如果满足条件⑥，那么以概率1转移到状态Train13.Train20表示列车2处于无连接状态，Train21表示列车2处于接收SDS 发送的应答器报文的状态，Train22表示列车2处于到达应答器BYX 时已经收到该应答器报文的状态，Train23表示列车2处于到达应答器BYX 时未收到该应答器报文的状态，Train24表示列车2处于到达应答器BX 时已经收到该应答器报文的状态，Train25表示列车2处于到达应答器BX 时未收到该应答器报文的状态.当列车2处于状态Train20时，以概率1转移到状态Train21.当列车2处于状态Train21时，如果满足条件⑦，那么以概率1转移到状态Train22；如果满足条件⑧，那么以概率1转移到状态Train23；如果满足条件⑨，那么以概率1转移到状态Train24；如果满足条件⑩，那么以概率1转移到状态Train25.Train30表示列车3处于无连接状态，Train31表示列车3处于接收SDS 发送的应答器报文的状态，Train32表示列车3处于到达应答器BYS 时已经收Fig.7　SDS module in probability model图 6　概率模型中的信道模块Fig.6　Channel module in probability model（a ）列车1模型列车2模型列车3模型（b ）（c ）图8　概率模型中的列车模块Fig.8　Train module in probability model9北京交通大学学报第 47 卷到该应答器报文的状态，Train33表示列车3处于到达应答器BYS时未收到该应答器报文的状态，Train34表示列车3处于到达应答器BS时已经收到该应答器报文的状态，Train35表示列车3处于到达应答器BS时未收到该应答器报文的状态.当列车3处于状态Train30时，以概率1转移到状态Train31.当列车3处于状态Train31时，如果满足条件⑪，那么以概率1转移到状态Train32；如果满足条件⑫，那么以概率1转移到状态Train33；如果满足条件⑬，那么以概率1转移到状态Train34；如果满足条件⑭，那么以概率1转移到状态Train35.信道模块、SDS模块、列车模块共同组成了无线广播通信场景的概率模型.采用PRISM语言描述建立场景的概率模型，具体的描述过程不再详细介绍.3.3无线广播通信场景概率模型形式化验证采用概率模型检验工具PRISM验证场景概率模型，设置无线通信信道无故障概率P1=0.9，通信误码率p e=1×10−6.目标是确定SDS的优先发送机制中规定的优先发送变化报文的次数N取2~6之间的任意整数是否合理，然后用概率计算树逻辑PCTL对待分析的性质进行描述.1）性质1：在一定的信道无故障概率和通信误码率下，当SDS的优先发送机制中规定的优先发送变化报文的次数N分别取2、3、4、5、6时，列车1运行至应答器BSI时，计算已经收到该应答器报文的概率PRISM语言：P=？［F （train1=2）］；其中train= 2表示列车1运行至~应答器BSI时已经收到该应答器的报文.性质1的验证结果如表4所示.2）性质2：在一定的信道无故障概率和通信误码率下，当SDS的优先发送机制中规定的优先发送变化报文的次数N分别取2、3、4、5、6时，列车2运行至应答器BYX时，计算已经收到该应答器报文的概率PRISM语言：P=？［F （train2=2）］；其中train2= 2表示列车2运行至应答器BYX时已经收到该应答器的报文，性质2的验证结果如表4所示.3）性质3：在一定的信道无故障概率和通信误码率下，当SDS的优先发送机制中规定的优先发送变化报文的次数N分别取2、3、4、5、6时，列车2运行至应答器BX时，计算已经收到该应答器报文的概率PRISM语言：P=？［F （train2=4）］；其中train2= 4表示列车2运行至应答器BX时已经收到该应答器表 4　性质1~性质5的验证结果Tab.4　V erification results of properties 1 to 5 N23456性质10.990 380.997 250.999 210.999 780.999 94性质20.985 430.995 840.998 810.999 660.998 81性质30.999 990.999 990.999 990.999 990.999 90性质40.985 430.995 83性质50.999 990.999 970.999 990.999 650.999 90表 3　无线广播通信场景概率模型中变量的含义Tab.3　T he meaning of variables in probability model of radio broadcast communication scenario变量P1 p e recs recf priorityNT1 T2 T3 T4 T5 recs1 recs2 recs3 recs4 recs5含义信道无故障概率车地通信的误码率SDS发送某个应答器的报文成功的次数SDS发送某个应答器的报文失败的次数SDS重复发送某个应答器报文的次数SDS的优先发送机制中规定的优先发送变化报文的次数（N取2~6之间的任意整数）列车1从开始运行至到达应答器BSI时所用的时间列车2从开始运行至到达应答器BYX时所用的时间列车2从开始运行至到达应答器BX时所用的时间列车3从开始运行至到达应答器BYS时所用的时间列车3从开始运行至到达应答器BS时所用的时间SDS发送应答器BSI的报文成功的次数SDS发送应答器BYX的报文成功的次数SDS发送应答器BX的报文成功的次数SDS发送应答器BYS的报文成功的次数SDS发送应答器BS的报文成功的次数表 2　无线广播通信场景概率模型中状态转移条件Tab.2　S tate transition conditions in probability model of ra⁃dio broadcast communication scenario数字①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭状态转移条件channel!=2；1-Pe: recs:=recs+1；priority:=priority+1；Pe: recf:=recf+1；priority:=priority+1；channel=2；recf:=recf+1；priority:=priority+1；priority<N；priority=N；t=T1；recs1>0；t=T1；recs1=0；t=T2；recs2>0；t=T2；recs2=0；t=T3；recs3>0；t=T3；recs3=0；t=T4；recs4>0；t=T4；recs4=0；t=T5；recs5>0；t=T5；recs5=0；10。

英语作文-揭秘集成电路设计中的功耗分析与优化方法Power analysis and optimization in integrated circuit (IC) design is a critical aspect that influences both the performance and efficiency of electronic devices. As technology advances, demands for lower power consumption in ICs have become increasingly stringent, driven by factors such as battery life in mobile devices, heat dissipation in high-performance computing, and environmental concerns. In this article, we will delve into various methods and strategies employed in the analysis and optimization of power consumption in IC design.Firstly, it's essential to understand the sources of power dissipation in ICs. The major contributors typically include dynamic power dissipation (P_dynamic), which arises from charging and discharging internal node capacitances during switching activities, and static power dissipation (P_static), caused by leakage currents in transistors even when they are not switching.To effectively analyze and optimize power consumption, designers employ several key methodologies:1. Power Estimation and Modeling:Before diving into optimization, accurate estimation of power consumption is crucial. This involves using tools and techniques to model power at various stages of the design process—from early architectural exploration to detailed circuit implementation. Power estimation tools simulate the behavior of the IC under different conditions (e.g., varying workloads or input signals) to predict power consumption accurately.2. Architectural Optimization:At the architectural level, design choices significantly impact power consumption. Techniques such as voltage and frequency scaling (DVFS), where the operating voltageand clock frequency are adjusted dynamically based on workload, are commonly used to achieve optimal power-performance trade-offs. Furthermore, employing low-power design architectures such as pipelining, parallelism, and data gating helps in reducing power consumption without compromising performance.3. Circuit-Level Optimization:Circuit-level optimizations focus on reducing both dynamic and static power dissipation. Techniques like clock gating, where parts of the circuit are selectively shut down when not in use, effectively reduce dynamic power consumption. Additionally, optimizing transistor sizing, using low-leakage transistors, and implementing efficient power gating techniques help in minimizing static power dissipation.4. Advanced Power Management Techniques:As ICs become more complex, advanced power management techniques are crucial. This includes sophisticated power gating strategies like multi-threshold CMOS (MTCMOS), where different parts of the chip can operate at different voltages or shut down independently. Furthermore, the integration of power islands allows certain blocks of the IC to operate autonomously, enabling further power savings.5. Verification and Validation:Throughout the design process, verification of power-related optimizations is essential to ensure they meet design goals. Techniques such as power-aware simulation and formal verification help in validating power reduction strategies early in the design cycle, thereby minimizing costly redesigns later.6. Post-Silicon Power Analysis:Post-silicon power analysis involves measuring actual power consumption on fabricated chips. This step validates earlier estimations and optimizations, providing feedback for future design iterations and improvements.In conclusion, the analysis and optimization of power consumption in IC design involve a comprehensive approach spanning from early architectural decisions to post-silicon validation. By employing advanced modeling, architectural optimizations, circuit-level techniques, and rigorous verification, designers can effectively meet stringent power constraints while maintaining optimal performance. This holistic approach not only enhances the efficiency and longevity of electronic devices but also contributes to sustainable and eco-friendly design practices in the semiconductor industry.。