简介:关于对不知道怎么写系统专家论文范文课题研究的大学硕士、相关本科毕业论文系统专家论文开题报告范文和文献综述及职称论文的作为参考文献资料下载。
（上海飞机设计研究院 上海 201210）
摘 要：专家意见是检查民用机载系统需求正确性和完整性的重要依据,因而系统工程师掌握有效应对各类专家问题的方法是十分必要的.通过分析专家意见处理中存在的各种问题,提出了新的以专家意见为主线的系统需求确认方法：搜集专家意见以确定系统范围,用系统规范中的术语系统结合多种手段来解答专家问题.搜集的过程要尽量避免专家对系统规范文本的逐字理解,而应该让专家根据自己专业的需要提出意见.解答的过程要直接证明专家意见能被系统规范定义的术语表示并能进行有效的推理,让专家肯定外部结论.该方法中角色职责清晰,能适应实际开发中团队合作和系统规范内容不稳定的特点,比现有方法更有效率.
关键词:系统工程 民用飞机 需求确认 专家意见
中图分类号：V37 文献标识码：A 文章编号：1674-098X（2014）08（b）-0066-03
在民用航空研制领域广泛使用的ARP4754A,民用飞机系统开发指南,推荐将系统与外界的接口需求以协议的方式形成机载系统规范.系统规范的具体形式包括工作说明、计划、手册、需求文档、接口文档或合同[1],是完整和详细的系统接口描述.从本体论的角度来看,系统规范就是机载系统的知识本体,是该系统“共享概念模型的明确的形式化规范说明”[2-3].除了该系统内部的系统工程师,共享这些知识概念的专家还包括适航代表,飞行员代表,软硬件工程师,系统验证工程师和其他相关系统的系统工程师等外部人员.以上所有专家会在飞机研制的不同阶段分别参与到该系统的确认过程.ARP4754A建议使用模板/检查单、用户操作场景描述和原型建模等确认方法来保障系统规范的正确性和完整性[1].这些方法在实际操作过程中普遍存在着以下问题：
（1）模板订制（裁剪、扩展和修改）缺乏依据.
（2）检查单项目含义模糊,难以判断.
（3）用户操作场景描述不准确或相关条件尚未确定.
（4）原型建模受问题特点的制约,使用范围有限.
因此,作为上述方法的重要补充,各类专家会根据各自的工作职责针对性地提出问题作为专家意见,参与到系统需求的确认过程中.汇总的专家意见是系统利益相关人对该系统的客观要求,是飞机设计评审中的重要参照,是飞机研制过程向前迈进和适航取证的必要条件,是决定民机项目成功的关键因素.所有系统工程师都很重视这些意见.不过,由于专家知识背景不同,描述问题的角度和层次不同,系统工程师如果直接纳入这些意见和反馈进行系统规范开发就会产生知识冲突.综合分析以上情况,本人提出以专家意见为主线的机载系统需求的确认方法,在一个新的系统工程框架下实现理论与实践的结合.
1.专家意见驱动的需求确认方法
系统规范的开发是一个迭代的过程,一开始就需要确定知识领域和系统范围.这将会涉及到以下基本问题：
（1）该系统规范覆盖什么领域?
（2）该系统规范用来干什么?
（3）该系统规范能回答哪些类型的问题?
（4）谁使用和维护该系统规范?
从本体论的角度看,专家意见就是一系列基于系统规范代表的领域知识模型应该能够回答的问题,即“资质性问题（Competency Questions）”[4].它能够有效确定系统知识的广度和深度,可以用来评价和比较现有的不同系统规范,也可以作为以后需求确认的有效参照.
系统规范草案出炉之后,部门会先组织内部评审.一般情况下,系统规范都会参照以往机型相似系统的设计文件和航空业适用于该系统的指导规范.一个容易出现的错误做法就是把系统规范与行业指导规范做比较,找出两者的差异,然后研究出现差异的原因和减少差异的措施.这种做法没有抓住问题的关键.行业指导规范大多不是强制标准,不针对任一机型,允许不同机型参考并根据需要进行裁剪,扩充和修改.这种适应性修改的依据,不是看与行业指导参考规范的差异,而应该是看能否满足飞机设计和适航的各种需求.
系统规范草案通过了内部评审就会进行外部评审.一般的做法就是把系统规范的草案分发到相关专业和适航机构,要求同行评审.这种做法也有问题.首先每个飞机系统都有一套独立的术语系统来保证描述的一致性和准确性.要让其他专业背景的系统工程师在短时间内理解和掌握这套新建的术语系统是有难度的.另外,由于飞机系统间的有机联系,从系统开始研制的相当长的时间内,系统规范的输入都没有办法完全确定,送审的系统草案本身也是不稳定的.草案不成熟蕴含的术语不一致性,会导致外专业评审人员从字面无法理解概念,提出的问题包含大量要求澄清概念的情形.当本系统工程师不得不花费时间和精力向外专业工程师讲解系统规范这个版本中的术语概念时,也注意到这些外部专家对概念的初步掌握对系统规范本身的质量提升一般不会起到很大作用.而实际上,外部专家并不真正关心这些概念.他们的最终目的在于确认能用系统规范中的概念表达他们感兴趣的问题并能推导出合理的外部结论.
系统论文范文:海尔太阳能系统专家2
通过对以上两种做法的分析,可以得出以下结论：系统需求的确认必须以专家意见为依据,以及确认的本质在于让专家明白系统规范能够表达他们关心的问题并能进行有效推理.因此,一种更好的确认方法是,系统工程师通过搜集专家意见来确定系统范围,并利用系统规范建立的领域知识模型来直接表示和解答专家意见,从而避免外部专家对系统规范的字面理解.以下分三个步骤来介绍这种需求确认方法的具体操作过程.
2.搜集专家意见
从系统研制启动就可以准备搜集专家意见.搜集问题可以从最简单的问题开始,然后逐步变得复杂.问题必须是具体的,要能够直接标识到飞机系统,设备,软件加载项或者硬件接口.问题需要有代表性,不必穷尽.
按问题来源,专家意见可以分为内部意见和外部意见.内部意见来自软硬件工程师,具体可以参考ARP4754A,4.6.1节“系统过程与配置项过程的信息流”.[1]来自诸如适航代表,飞行员代表,系统验证工程师和其他相关系统的系统工程师等系统外部人员的意见称为外部意见.需要特别注意的是系统验证工程师的尽早介入.系统需求的验证工作是在系统设备试验件提交之后,系统验证工程师按照既定的试验大纲进行试验并逐个确认是否满足预期结果.不过,为了尽早暴露问题,提高系统需求的可验证性,避免验证工程师误解系统概念导致的试验问题和不必要的进度延误,试验大纲也将作为专家问题的重要来源.
根据表述类型,专家问题又可以分为以下四类：[4-6]
存在性问题.某个对象是否存在?专家问题里涉及的概念需要明白无误地与特定飞机系统或部件对应.比如驾驶舱显示器的燃油简图页画面上有没有表示燃油温度的指示标识.
属性的问题.对象的属性是什么?通过某个飞机系统或系统部件找出所有的内在属性.比如,高升力系统的襟翼张开的角度是多少.
关系的问题.两个对象之间是这个关系吗?在不同状态下,要求明确给出不同系统或系统部件之间的关系.比如,在飞机单个发动机飞行状态下,哪些飞行画面要优先展示给飞行员.
推理的问题.回答这样的专家问题需要基于一定的规则或逻辑推理.在实例化系统或系统部件属性之后,可以根据这些数据进行有意义的推理.比如,在航电的IMA资源分配的时候,在保证现有平台资源安全冗余的条件下,能否为飞控系统的某驻留功能分配20ms的周期性运行时间.
专家问题的提出不依赖任何目标系统规范的知识,只要是对专家所在系统的研制有意义就可以.专家问题需要由相关部门进行正式的认定和签发,确实代表该部门对目标系统的实际要求.
3.解答专家问题
在确立系统架构进行系统设计过程中,系统工程师就可以利用规范里的术语来表达专家意见,以衡量系统规范的成熟度.系统工程师通过列写出专家问题中的重要词汇,与搜集到的参考资料中的概念进行分析比较,可以判断这些参考资料的复用程度和使用价值.[5-6]
系统规范写好后,大多数专家问题都应该得到了解决.当然,考虑到专家的知识背景和特殊的观察视角,系统工程师不可能完全理解专家意见中所有词汇的含义.这需要和有关专家进行沟通,进一步挖掘用户和客户需求.不过,这与让专家学习系统规范不同的地方在于,系统工程师在理解了问题含义后,转换成自己熟悉的系统专业词汇来回答对方专家认为重要的问题,而不是学习对方词汇来进行表达和推理.在双方都在描述同一个知识领域的前提下,这点是可以在短时间内做到的.
上面已经提到,解答专家意见的过程就是利用新建系统规范的概念表示问题,并用定义的属性和关系对问题进行推导的过程.简单的问题,一句话就可以说清楚.对于复杂的情况,则可以使用用例/故事,描述操作场景,编写具体算法或者测试用例的方式来说明.某些特定的复杂问题还可以借助Enterprise Archtect,Rational Rhapsody或CATIA等CASE工具,用UML/SysML模型或数字三维模型来回答问题.例如,在IMA的资源分配过程中就可以利用UML对驻留应用进行建模并利用内置算法来自动优化计算和通信资源.对于保真度要求较高的问题,还可以使用模拟器仿真.比如,评估驾驶舱显示方案就可以在驾驶舱模拟器中进行,让飞行员和有关专家身临其境地评价和比较不同显示方案的优劣.
让专家仅凭阅读文档就表决通过一份系统规范是不现实的.以上各种手段的目的都是尽可能直接地向专家展示系统规范的表达能力和令人满意的推理结果,让对方相信他们关心的问题能够利用系统规范得到解答.具体做法上,在系统规范和问题演示材料准备好后,先发送给对方专家并进行多次面对面或者邮件沟通,尽可能地达成一致意见.对于有分歧的部分,则可以由部门出面组织研讨会,讨论修改意见或者解决办法.在飞机研制的重要评审会上,不仅要把定型的系统规范分发到相关专家和项目负责人,还要汇总说明各类专家问题的解决情况.对于影响较大的遗留问题,还需要在评审会上进行单独讨论.
4.总结经验/教训
专家意见的搜集和解答情况不仅仅标志着系统规范的成熟度,还体现着系统工程师对用户需求理解的深度和广度.每个问题的成功解答都是一个进步.即便系统规范还会随着飞机研制的深入而变更,问题的表述方式会变化,但原理和实质不会变.之前通过表达和解决问题与专家达成的共识仍然有价值,解决问题的方法也可以借鉴的.而且,解决专家问题的过程也是和专家互动的过程.良性的沟通可以与专家建立了令人愉快的工作关系.
不可否认的是,肯定存在着某些问题不能得到很好表示或者推理无法令对方满意的情况.对方专家指出的演示过程中的不合理部分将激发系统工程师对现有系统规范中的架构设计和需求描述方式的深入思考.对于有争论问题,可以组织更高层级或者更大范围的讨论,听取更多人的意见.确实有问题的要修改,即使系统规范要论文范文重来,也是值得的.在概念和开发阶段就发现问题并纠正,避免在验证和生产运营阶段出现更为严重的错误,这正是系统需求确认活动的意义.[1]
专家意见的解答方法可以写成工程协调纪要,以备将来参考和复用.一些解答问题的方法,例如算法,模型和原型等,都可以作为系统后续设计的重要参考.另外,解决的专家问题也是培训员工迅速了解本系统领域知识和工作方法的有效的第一手学习资料,可以帮助新员工或者刚接手相关事务的员工尽快上手,提高团队工作效率.
5.结语
民用机载系统需求的确认是一个复杂的过程.一方面要多领域专家共同参与,广泛听取各方意见,另一方面,要有专门的术语系统,维护规范的内部一致性和准确性.这就需要从系统工程的高度进行顶层设计.本文提出以专家意见为纽带构建一个框架：内部由系统工程师维护一套一致的、可自我辩护的术语体系；外部则让不同角色的利益相关人都能在自己的知识层次上提出问题,并通过系统工程师的演示来确认在系统规范的知识体系内确实可以找到问题的合理解答,满足预期的接口需求.本文提出的方法汲取了本体论研究成果,能够较好满足现有的航空工程实践基础的要求.
参考文献
[1]SAE,ARP4754 REV.A,2010. Guidelines for Development of Civil Aircraft and Systems[Z].
[2]Borst,W.N.Constructing of Engineering Ontologies.PhD thesis, Institute for Telematica and Information Technology, University of Twente, Enschede, The Netherlands[Z].1997.
[3]Gómez-Pérez, A.Knowledge sharing and reuse. Handbook of Applied Expert Systems. Liebowitz, editor, CRC Press[Z].1998.
[4]Gruninger, M. and Fox, M.S. Methodology for the Design and Evaluation of Ontologies. In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing,1995,IJCAI-95, Montreal[Z].
[5]Gruber, T.R.A Translation Approach to Portable Ontology Specification[J].Knowledge Acquisition,1993,5:199-220.
[6]Uschold,M.and Gruninger,M. Ontologies:Principles,Methods and Applications[J].Knowledge Engineering Review,1996,11（2）.
[7]RTCA,DO-178C,Software Considerations in Airborne Systems and Equipment Certification[Z].2012.
[8]RTCA, DO-254,Design Assurance Guidance for Airborne Electronic Hardware[Z].2000.
[9]RTCA, DO-297,Integrated Modular Avionics （IMA） Development Guidance and Certification Considerations[Z].2005.
总结：本文是一篇关于系统专家论文范文，可作为相关选题参考,和写作参考文献。
系统论文范文引用文献:
[1] 专家论文范文 关于专家论文范本2万字
[2] 教育专家论文范文 教育专家方面有关专科毕业论文范文2万字
[3] 专家论文范文 关于专家论文写作资料范文5000字
