《Software factory techniques applied to Process Control at CERN.doc》由会员分享，可在线阅读，更多相关《Software factory techniques applied to Process Control at CERN.doc（6页珍藏版）》请在三一文库上搜索。
1、SOFTWARE FACTORY TECHNIQUES APPLIED TO PROCESS CONTROL AT CERN Mathias Dutour, CERN, Geneva, Switzerland Abstract The CERN Large Hadron Collider (LHC) requires constant monitoring and control of quantities of parameters to guarantee operational conditions. For this purpose, a methodology called UNIC
2、OS (UNIfied Industrial COntrols Systems) has been implemented to standardize the design of process control applications. To further accelerate the development of these applications, we migrated our existing UNICOS tooling suite toward a software factory in charge of assembling project, domain and te
3、chnical information seamlessly into deployable PLC (Programmable logic Controller) SCADA (Supervisory Control And Data Acquisition) systems. This software factory delivers consistently high quality by reducing human error and repetitive tasks, and adapts to user specifications in a cost-efficient wa
4、y. Hence, this production tool is designed to encapsulate and hide the PLC and SCADA target platforms, enabling the experts to focus on the business model rather than specific syntaxes and grammars. Based on industry standard software, this production tool together with the UNICOS methodology 1 prov
5、ides a modular environment meant to support each process control expert to develop his solutions quickly. This article presents the user requirements of the software factory and the chosen approach. Then the focus moves to the benefits of the selected architecture, and ends up with the results and a
6、 vision for further improvements. INTRODUCTION The large scale process control applications developed at CERN cannot be presented as a production line, but rather as custom-designed applications in constant evolution during their lifecycles. This evolution during the development phase is dictated ei
7、ther by extensions to the system or by applying corrections and implies the need for often regenerating the process control applications. Therefore the maintenance on the long term of the tools to produce such process control applications is critical. With these ideas in mind, a software factory 2,
8、also called the UAB (UNICOS Application Builder) tool, was designed to enable faster and cheaper code generation in a context of often changing requirements. DRIVING REQUIREMENTS Besides the limitations of the existing code generation tools 3, the users expect more support and efficiency from the UA
9、B, to focus only on their field of expertise and to be able to reuse the assets they produced across teams and projects. Extensibility Process control applications are subject to many extensions. Typical examples: a new type of physical device has to be integrated or additional parameters are requir
10、ed for process control logic. The UAB tool reflects this versatility and provides the means to integrate seamlessly these new elements. Additionally, the assets produced by the team for this integration work, are valuable and directly reusable in a different context for another team, thus increasing
11、 productivity. Since the domain knowledge involved in the development of a process control application is not platform specific (e.g.: PLC vendor independent), the UAB tool provides the required support to guarantee the reusability of the business assets produced as well. On the same level, it also
12、means the UAB tool can be easily extended to address new platforms without starting from scratch again and again. Separation of concerns The inputs and outputs of the UAB tool are handled by several people with different expertise and responsibilities. Typically the description of the project data,
13、i.e. the field-level description of the process control application, is realized by a System developer, while its business logic is the responsibility of a Domain expert. Finally the PLC or the SCADA developer is responsible for the integration and the deployment of the generated application. For th
14、e UAB tool it is therefore important to decouple these different aspects and keep them separate from the UAB tool internals. Consistency checking support The consistency checking support offered by the UAB tool is implemented at different levels: First an unambiguous means to feed the information in
15、to the code generation process is provided, enforced through the use of predefined models. Second, the UAB tool provides the users with powerful means to validate the semantic consistency of the code generation process inputs. The objective here is to detect and fix issues as early as possible durin
16、g the development phase. Finally, the UAB tool reports to the users any problems identified during the code generation and provides automatically hints for resolution. ARCHITECTURE More than a simple tool, the UAB tool is rather an approach to deal with automatic code generation. The central idea of
17、 the UAB architecture is to decouple the low-level information of the project (rather descriptive), from the usage of this information (the domain knowledge), from the project instantiation itself (the platform-specific generated code). The various packets implementing this approach together with th
18、e stakeholders are presented below: Raw project data and Grammar check packets The Raw project data typically contains the information describing the process control system itself, and is therefore target-platform dependent (i.e. it describes platform-specific PLC and SCADA information). However, it
19、 doesnt describe how this information shall be used for the code generation process. This project data is likely to be updated on a regular basis during the project development phase, as the user requirements are received and integrated. The chosen format to gather this information is XML (eXtended
20、Markup Language), the de facto industry standard and vendor independent dataencapsulation language. XML allows this data to be constrained by an XML schema, presented here as the Grammar check” packet in the Figure 1. Unlike the Raw Project data files, the Grammar check packet contains only structur
21、al definition and is designed as an extensible asset to be shared across process control projects. The Grammar check packet structure is known by the Code generation rules packet and used by the UAB Tool packet to generate an internal representation of the Raw project data. This internal representat
22、ion is managed by the JAXB 45(Java Architecture for XML Binding) library. Thanks to JAXB, the extension or structural modification of the Raw project data can be realized on the fly with no need to modify the UAB Tool and immediate availability to the Code generation rules. Code generation rules pac
23、ket Just like the orchestra conductor, the Code generation rules dont contain any data, but simply encapsulate the business knowledge of the output expected. Their primary goal is to drive the code generation through a set of abstract services. (E.g.: same rules apply whatever the PLC target platfor
24、m is) By focusing on the “What” rather than on the “How”, the Domain expert in charge of the Code generation rules can focus only on the system behaviour he expects. The Code generation rules have been designed to enable platform syntax abstraction, a step away from error prone syntaxes. To achieve
25、their goal, the Code generation rules have at their disposal two handles. A first handle on the Raw project data to extract any relevant information, and a second one on the code generation services of the UAB Tool to dictate what to do with this information: The flow of operations is the following:
26、 The Code generation rules accesses the UNICOS Project data (Step 1), possibly verifying or pre-processing this data, then calls abstracts services of the UAB tool (Step 2), which in turn generates the related pieces of code with the proper syntax (Step 3). Concretely, the Code generation rules cons
27、ist of a set of files written in a scripting language. The Jython 6 (Python for Java) language was chosen for this purpose, as it integrates perfectly with the UAB Tool and provides extensive functionality. Using such a scripting language rather than a flat properties file allows very powerful const
28、ructions. It allows the Domain expert, first to perform consistency and semantic checks on the Raw Figure 1: UAB tool context. Figure 2: Project information. Figure 3: Code generation principle. project data, and second to request code generation services possibly adapting dynamically to the current
29、 context. UAB Tool packet The UAB tool main packet is actually a container for platformspecific code generation plugins. To minimize maintenance, the UAB Core itself follows the broker design pattern and provides the plugins with an extensive set of high level interfaces (see Figure 4). The UAB Core
30、 is also in charge of other traditional aspects as well, such as graphical user interface, command line handling, file management, online error logging, etc.: To achieve the objective of extensibility, the UAB Core is highly configurable and has no static knowledge of its plug-ins, the content of th
31、e Code generation rules, or even any UNICOS concepts. The chosen language for the development of the UAB Core and its plug-ins is Java. Java permits high coding productivity and abstraction mechanisms such as introspection and runtime class loading, which are used efficiently by the UAB Core to dyna
32、mically adapt to its environment. UAB Tool plug-ins The plug-ins managed by the UAB Core are independent from each other and have different responsibilities. They are only focussed on pure code generation aspects; and know how to transform the abstract requests of the Code generation rules into prop
33、er vendor-specific source code. For example, one of our plug-in is responsible for the Schneider UNICOS PLC code generation and simply knows how to instantiate PLC objects and map them in PLC memory. For the rest the plug-in relies on the UAB Core mechanisms. All plug-ins are built onto the same mod
34、el. Each one can interact with the Code generation rules, access the Raw project data, and use UAB Core interfaces. Having a reusable model makes it easy to develop and integrate new plug-ins, even with little programming experience. BENEFITS The software factory approach, implemented here in the co
35、ntext of process control, allows to focus on the expected result rather than on the means to produce this result. Mixing static configuration, auto-adaptive software and abstract user directives, the UAB tool is a powerful and yet simple ruledriven code generation environment. The project technical
36、data, business logic and tooling configuration are clearly separated preventing the spaghetti plate effect: The long term maintenance of the process control applications is made safer and cheaper. The multi-level error checking mechanisms addressing grammar, syntax and semantic aspects filter-out ma
37、ny mistakes which could be difficult to detect before deployment and therefore very costly to track down and fix. Nonetheless, this approach is not self sufficient and does enforce on the onward a rigorous design of the project constructions to be used, such as the Grammar check and Code generation
38、rules packets. This is also to the direct benefit of the quality of the process control application produced. CONCLUSION At this date the UAB Core is being finalized while various UNICOS plug-ins are well advanced, namely for the PLC objects code generation on the Schneider Unity platform and their
39、supervision counterpart on the PVSS SCADA. Siemens Step7 plug-ins are under development as well for objects and control logic code generation. However, the UAB is not limited to UNICOS or even code generation, and its architecture can adapt to many domains with a need for a flexible offline data pro
40、cessing solution. REFERENCES 1 Philippe Gayet and Renaud Barillere, “UNICOS A framework to build Industry like control systems: Principles and methodology”, CERN, Geneva, Switzerland. 2 Jack Greenfield and Keith Short, “Moving to Software Factories”, Microsoft Corporation. 3 G. Thomas, “LHC GCS: A m
41、odel-driven approach for automatic PLC and SCADA code generation”, CERN, Geneva, Switzerland. 4 The GlassFish community, 5 Joseph Fialli and Sekhar Vajjhala, Sun Microsystems Inc. “The Java Architecture for XML Binding (JAXB)”, January 8th 2003. 6 The Jython Project, http:/www.jython.org. Figure 4:
42、UAB tool packet internals 我的大学爱情观我的大学爱情观 1 1、什么是大学爱情：、什么是大学爱情： 大学是一个相对宽松，时间自由，自己 支配的环境，也正因为这样，培植爱情之花 最肥沃的土地。大学生恋爱一直是大学校园 的热门话题，恋爱和学业也就自然成为了大 学生在校期间面对的两个主要问题。 恋爱关系处理得好、正确，健康，可以 成为学习和事业的催化剂，使人学习努力、 成绩上升；恋爱关系处理的不当，不健康， 可能分散精力、浪费时间、情绪波动、成绩 下降。因此，大学生的恋爱观必须树立在健 康之上，并且树立正确的恋爱观是十分有必 要的。因此我从下面几方面谈谈自己的对大 学爱情观
43、。 2 2、什么是健康的爱情：、什么是健康的爱情： 1) 尊重对方，不显示对爱情的占有欲，不 把爱情放第一位，不痴情过分； 2) 理解对方，互相关心，互相支持，互相 鼓励，并以对方的幸福为自己的满足; 3) 是彼此独立的前提下结合； 3 3、什么是不健康的爱情：、什么是不健康的爱情： 1)盲目的约会，忽视了学业; 2)过于痴情，一味地要求对方表露爱的 情怀，这种爱情常有病态的夸张; 3)缺乏体贴怜爱之心，只表现自己强烈 的占有欲; 4)偏重于外表的追求; 4 4、大学生处理两人的在爱情观需要、大学生处理两人的在爱情观需要 三思：三思： 1. 不影响学习： 大学恋爱可以说是一种必要的经历，学习是
44、 大学的基本和主要任务，这两者之间有错综 复杂的关系，有的学生因为爱情，过分的忽 视了学习，把感情放在第一位；学习的时候 就认真的去学，不要去想爱情中的事，谈恋 爱的时候用心去谈，也可以交流下学习，互 相鼓励，共同进步。 2. 有足够的精力： 大学生活，说忙也会很忙，但说轻松也是相 对会轻松的！大学生恋爱必须合理安排自身 的精力，忙于学习的同时不能因为感情的事 情分心，不能在学习期间，放弃学习而去谈 感情，把握合理的精力，分配好学习和感情。 3、有合理的时间； 大学时间可以分为学习和生活时间，合理把 握好学习时间和生活时间的“度”很重要； 学习的时候，不能分配学习时间去安排两人 的在一起的事情
45、，应该以学习为第一；生活 时间，两人可以相互谈谈恋爱，用心去谈， 也可以交流下学习，互相鼓励，共同进步。 5 5、大学生对爱情需要认识与理解，、大学生对爱情需要认识与理解， 主要涉及到以下几个方面：主要涉及到以下几个方面： （1）明明确确学学生生的的主主要要任任务务 “放弃时间的人，时间也会放弃他。 ”大学时代是吸纳知识、增长才干的时 期。作为当代大学生，要认识到现在的 任务是学习学习做人、学习知识、 学习为人民服务的本领。在校大学生要 集中精力，投入到学习和社会实践中， 而不是因把过多的精力、时间用于谈情 说爱浪费宝贵的青春年华。因此，明确 自己的目标，规划自己的学习道路，合 理分配好学习和
46、恋爱的地位。 （2） 树树林林正正确确的的恋恋爱爱观观 提倡志同道合、有默契、相互喜欢 的爱情：在恋人的选择上最重要的条件 应该是志同道合，思想品德、事业理想 和生活情趣等大体一致。 摆正爱情与学习、事业的关系：大 学生应该把学习、事业放在首位，摆正 爱情与学习、事业的关系，不能把宝贵 的大学时间，锻炼自身的时间都用于谈 情说有爱而放松了学习。 相互理解、相互信任，是一份责任 和奉献。爱情是奉献而不时索取，是拥 有而不是占有。身边的人与事时刻为我 们敲响警钟，不再让悲剧重演。生命只 有一次，不会重来，大学生一定要树立 正确的爱情观。 （3） 发发展展健健康康的的恋恋爱爱行行为为 在当今大学校园
47、，情侣成双入对 已司空见惯。抑制大学生恋爱是不实际 的，大学生一定要发展健康的恋爱行为。 与恋人多谈谈学习与工作，把恋爱行为 限制在社会规范内，不致越轨，要使爱 情沿着健康的道路发展。正如马克思所 说：“在我看来，真正的爱情是表现在 恋人对他的偶像采取含蓄、谦恭甚至羞 涩的态度，而绝不是表现在随意流露热 情和过早的亲昵。” （4 4）爱情不是一件跟风的事儿。爱情不是一件跟风的事儿。 很多大学生的爱情实际上是跟风的 结果，是看到别人有了爱情，看到别人 幸福的样子（注意，只是看上去很美）， 产生了羊群心理，也就花了大把的时间 和精力去寻找爱情 （5 5）距离才是保持爱情之花常距离才是保持爱情之花常
48、 开不败的法宝。开不败的法宝。 爱情到底需要花多少时间，这是一 个很大的问题。有的大学生爱情失败， 不是因为男女双方在一起的时间太少， 而是因为他们在一起的时间太多。相反， 很多大学生恋爱成功，不是因为男女双 方在一起的时间太少，而是因为他们准 确地把握了在一起的时间的多少程度。 （6 6）爱情不是自我封闭的二人爱情不是自我封闭的二人 世界。世界。 很多人过分的活在两人世界，对身边的 同学，身边好友渐渐的失去联系，失去了对 话，生活中只有彼此两人；班级活动也不参 加，社外活动也不参加，每天除了对方还是 对方，这样不利于大学生健康发展，不仅影 响学习，影响了自身交际和合作能力。 总结：总结： 男女之间面对恋爱，首先要摆正好自己 的心态，树立自尊、自爱、自强、自重应有 的品格，千万不要盲目地追求爱，也不宜过 急追求爱，要分清自己的条件是否成熟。要 树立正确的恋爱观，明确大学的目的，以学 习为第一；规划好大学计划，在不影响学习 的条件下，要对恋爱认真，专一，相互鼓励， 相互学习，共同进步；认真对待恋爱观，做 健康的恋爱； 总之，我们大学生要树立正确的恋爱观 念，让大学的爱情成为青春记忆里最美的风 景，而不是终身的遗憾！