SoftwarefactorytechniquesappliedtoProcessControlatCERN.doc

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 unicos (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 technical 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 way. 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 provides 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 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 either 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, 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 uab, 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 required 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 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 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, 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 the 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 into 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 during 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 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 the 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 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 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 structural 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 representation 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 packet 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 platform 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 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: 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 consist 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 constructions. 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 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 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 the 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 dynamically 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 proper 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 model. 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 context 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 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 many 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 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 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 processing 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 model-driven approach for automatic plc and scada code generation”, cern, geneva, switzerland. 4 the glassfish community, /javaee/community/glassfish/ 5 joseph fialli and sekhar vajjhala, sun microsystems inc. “the java architecture for xml binding (jaxb)”, january 8th 2003. 6 the jython project, . figure 4: uab tool packet internals 我的大学爱情观我的大学爱情观 1 1、什么是大学爱情：、什么是大学爱情： 大学是一个相对宽松，时间自由，自己 支配的环境，也正因为这样，培植爱情之花 最肥沃的土地。大学生恋爱一直是大学校园 的热门话题，恋爱和学业也就自然成为了大 学生在校期间面对的两个主要问题。 恋爱关系处理得好、正确，健康，可以 成为学习和事业的催化剂，使人学习努力、 成绩上升；恋爱关系处理的不当，不健康， 可能分散精力、浪费时间、情绪波动、成绩 下降。因此，大学生的恋爱观必须树立在健 康之上，并且树立正确的恋爱观是十分有必 要的。因此我从下面几方面谈谈自己的对大 学爱情观。 2 2、什么是健康的爱情：、什么是健康的爱情： 1) 尊重对方，不显示对爱情的占有欲，不 把爱情放第一位，不痴情过分； 2) 理解对方，互相关心，互相支持，互相 鼓励，并以对方的幸福为自己的满足; 3) 是彼此独立的前提下结合； 3 3、什么是不健康的爱情：、什么是不健康的爱情： 1)盲目的约会，忽视了学业; 2)过于痴情，一味地要求对方表露爱的 情怀，这种爱情常有病态的夸张; 3)缺乏体贴怜爱之心，只表现自己强烈 的占有欲; 4)偏重于外表的追求; 4 4、大学生处理两人的在爱情观需要、大学生处理两人的在爱情观需要 三思：三思： 1. 不影响学习： 大学恋爱可以说是一种必要的经历，学习是 大学的基本和主要任务，这两者之间有错综 复杂的关系，有的学生因为爱情，过分的忽 视了学习，把感情放在第一位；学习的时候 就认真的去学，不要去想爱情中的事，谈恋 爱的时候用心去谈，也可以交流下学习，互 相鼓励，共同进步。 2. 有足够的精力： 大学生活，说忙也会很忙，但说轻松也是相 对会轻松的！大学生恋爱必须合理安排自身 的精力，忙于学习的同时不能因为感情的事 情分心，不能在学习期间，放弃学习而去谈 感情，把握合理的精力，分配好学习和感情。 3、有合理的时间； 大学时间可以分为学习和生活时间