Embedded system design using uml and platforms

偏重性格的自我介绍(精选多篇)第一篇：偏重性格的自我介绍我拥有双重性格，好的时候，可以将自己聪明、细腻、能干、温情、幽默、有内涵等优良品质完全外展，此时我显得如此完美，光芒四射，并且可以表现得非常外向、健谈，容易与人打成一片。

而一旦状态不好，便会变成另一个人，甚至非常窝囊，一事无成，不过通常此时我都躲了起来，不会让人看见。

正因我深知自己这样的性格，理智的我选择了在状态好时多做事，多活动，多完成些人生目标，因为我无法确知何时糟糕的状态会到来，甚至有时为此不得不推迟自己的计划，或出现让人难以理解的行为模式。

这种状态的变化表现在人际交往上特别是恋爱中便是忽冷忽热。

因此，我需要绝对的安全感，这是一种说不清道不明的东西，反正就是不会让我感到不舒服，易诱发糟糕状态的感觉。

很多时候，安全感来自于他们独有的私人空间。

总之，状态好时，我是大众的宠儿;状态不好时，却是世界的逃兵。

我的这种性格让爱我的人感到委屈和无助，我的情绪善变。

也不仅仅是多愁善感一词可以概括，很多时候我会莫名地陷入悲痛和自责中。

在冷时，我最希望躲进自己一个人的世界里，独自在孤独和冷漠中调整自己的情绪，等心事已了时再走出来。

然而世界并不我而转，很多时候我要面对很多实际的琐事，这时的我便不得不在冷中面对周围世界：要么说话做事很不自然，有做作的痕迹;要么便极度冷漠和被动，对谁都不理不睬。

其实我很清楚自己现在的样子，但我无力改变和控制自己的情绪，只能选择疯狂地逃避一切。

我想的是：与其很不自然地面对你，尴尬地和你说些无关痛痒地话，或是因和平时反差太大而被人说成表里不一、性格怪异，还不如先躲一阵子，等调节好了以后再出来。

所以，在与人交往中，我只会和不得不交流的人或是完全陌生的人交谈，而和熟悉的朋友反而疏远。

你在他心中地位越重，我躲得你越远。

特别是你，我只会让你感觉到我的存在，而不让你触碰到我或是见到我，若即若离的感觉。

原因很简单：我只想给你一个最好最完美的自己，而不愿让你看到我无助脆弱的一面。

Model-Based Development ofEmbedded SystemsFranz Huber, Jan Philipps, Oscar SlotoschValidas AGwww.validas.de{huber,philipps,slotosch}@validas.deAbstractWe describe concepts and processes for model-based development of embedded control systems. Tool support for such an approach is provided by the award-winning AutoFocus/Quest tool set jointly developed by TU München and Validas AG. We outline real-time extensions for the mod-eling languages and show how to use time information for testing. A small case study demon-strates these extensions.IntroductionSoftware development approaches that rely on modeling a system before performing the actual implementation work have a long history in computing. Among the first ones were data(base) modeling approaches using the Entity/Relationship model and similar other techniques. During further development, modeling techniques became increasingly complete, covering not only data aspects, but also structural/topological and behavioral aspects of systems. Typical representatives of such full-scale modeling approaches are structured methods, such as Structured Analysis & Design, or object-oriented methods like the UML [4].Models created in such a modeling language can serve different purposes. They can be regarded as a concise, much more formal version of otherwise informally given system requirements. In this view, they serve as a precise guideline for the developers that perform the actual implemen-tation work, and can furthermore be used as a basis for testing the conformance of the imple-mentation with the requirements.If a modeling language is rich enough to allow the creation of complete models (models that en-compass all aspects of a system on an abstract, implementation-independent level), another pur-pose of such models is obvious: The created models can not only be used to precisely capture the requirements upon the system, but to describe the system in detail, reaching up to a complete description of all aspects of the system. From such a complete description, it is basically possible(although not always feasible or desired in practice) to generate a complete system implementa-tion automatically. An important advantage of such a model-based approach is (programming) language independence: Modeling languages are usually driven by the application domain that they are used in and provide application-oriented abstractions to describe systems (components, data entities, states, state transitions, etc.). In contrast, typical programming languages such as Ada or C are general-purpose languages, providing language elements that reflect the underlying machine model of sequential execution of statements. Using code generation techniques to create implementations, such complete models as described previously can be transformed into imple-mentations in arbitrary programming languages.Models are abstractions of a system and are thus particularly less “cluttered” than an implemen-tation, for instance, in C. Therefore, it is much more promising for models than for implementa-tions to apply validation techniques, such as—covering different levels of formality—prototyping and simulation [7], test case/test sequence generation [12], or model checking [9]. If the elements of a modeling language have been chosen carefully enough to keep the modeling language sim-ple, yet complete, it is feasible to provide a sufficiently streamlined formal semantics that even allows the application of rigid formal validation/verification techniques [5].Subsequently, we introduce such a simple, yet powerful modeling language—the AutoFocus modeling language & framework [8]—and outline some of the validation techniques that can be applied to AutoFocus models. The AutoFocus modeling language has been under development since 1995, specially aimed at the development of embedded systems, and shares some concepts with UML/RT.Model-based Development ConceptsA modeling language—quite similar to a programming language—comprises a set of concepts that are used to describe systems. In case of programming languages, these concepts are typically statements, blocks, procedures, functions, and many more. For the AutoFocus modeling language and toolset, these concepts are based on the idea of a system being made up of a network of communicating components. Usually, the concepts that describe a modeling language are defined in a so-called meta-model (i.e., a model that describes how models in that modeling language can be constructed). A simplified representation of the AutoFocus meta-model is shown in Fig. 1, using the UML class diagram notation as the meta-language.AutoFocus Modeling ConceptsThe core modeling concepts of AutoFocus, i.e., the core elements in the its meta-model are as follows:Components. They are the main building blocks for systems. Components encapsulate data, in-ternal structure, and behavior. Components can communicate with their environment via well-defined interfaces. Components are concurrent: Each one of them runs sequentially; however, in a set of components, each component’s run is independent of the other components’ runs. Com-ponents can be hierarchically structured, i.e., consist of a set of communicating sub-components. Data types. They define the data structures used by components. Data types are constructed from a set of basic types (such as integer or float) and a set of constructors, e.g., for record and variant types.Data. Data elements are encapsulated by a component and provide a means to store persistent state information inside a component. Data elements can be regarded as typed state variables. Ports. They are a component’s means of communicating with its environment. Components read data on input ports and send data on output ports. Ports are named and typed, allowing only spe-cific kinds of values to be sent/received on them.Channels. They connect component ports. Channels are unidirectional, named, and typed, and they define the communication structure (topology) of a system.Control States and Transitions. These elements define the control state space and the flow of control inside a component. Each transition connects two distinct controls states (or one control state with itself, in case of a loop transition) and carries a set of four annotations determining its firing conditions (its “enabledness”):•pre-conditions and post-conditions, which are predicates over the data elements of the component to be fulfilled before and after the transition, respectively, and •input and output patterns, determining which values must be available on the compo-nent’s input ports to fire the transition and which values are then written to the output ports.Fig. 1. Basic Modeling Concepts of A UTO F OCUS: The Meta-ModelThese concepts are sufficient to describe a large class of systems. Developers create the model of an actual system using these concepts; technically speaking (e.g., with a modeling tool for this language in mind), an actual system model is an instance of this meta-model. The complete meta-model, together with a set of additional conditions relating to consistency and completeness of models, describes the set of all possible, well-formed models that can be created.Views and Description TechniquesDevelopers do not create and manipulate models as a whole, but by picking only specific parts of them, which are of interest during particular development activities. These parts, usually closelyrelated with each other, make up the views of the system. For instance, the structural view in A UTO F OCUS considers only elements from the meta-model describing the interface of compo-nents and their interconnection.To manipulate elements of these views we must represent them visually. In A UTO F OCUS we use mainly graphical notations for that purpose; these notations are introduced in more detail by our application example. The notations do not represent self-contained documents; instead they are a mere visualization of a clipping from the complete model. Fig. 2 shows an example for this rela-tionship between a set of related elements from the meta-model (inside the shaded area) and their visual, diagrammatic representation. In this example, structural aspects of the model are covered, and the notation used to visually represent them is called System Structure Diagrams (SSDs for short).b l e O pFig. 2. Structural Parts of the Meta-Model and the Notation representing them Model-based Development ProcessOne of the main difficulties in software engineering is that the requirements of the customer are prone to change while software is being developed. In standard waterfall development process models, which are still regularly used in industry, requirements analysis and testing are located at opposite ends of the development process. Evolutionary development processes, on the other hand, try to alleviate this problem by building the software system incrementally. Requirements are not fixed in an early development phase, but instead converge during several incremental cy-cles with customer interaction after completion of each increment.In this section, we first give a short overview over incremental development processes, and then describe how a process based on executable models is supported by modern CASE tools, such as AutoFocus. Finally, we explain the step from executable models to final code.Incremental DevelopmentBoehm’s spiral model [3] is the most famous incremental process model, although it is more a meta-model of a process than a proper development process model. More helpful for real soft-ware development are the Cleanroom Reference Model (CRM) [11], and so-called agile ap-proaches, most notably Extreme Programming (XP) [2], which is based on classical object-oriented programming languages.We believe that modeling languages fit the demands of an incremental process better than pro-gramming languages: Their higher level of abstraction leads to higher productivity of the devel-opers; their suggestive notations ease interaction with the customer and other developers. Never-theless, models are executable, which results in immediate feedback for the designer and the customer.The idea of incremental model-based development amounts to specifying the model of the system as precisely as possible, so that the model is always executable. In order to handle the complexity of the system, in a first step only a small part of the core functionality of the system is described. The specification is then (together with the customer) validated and verified by simulation, in-spection and reviews, and by formal verification and analysis techniques. Later steps refine this model: More components are added to the model in order to add functionality; the behavioral specifications of the components are elaborated to handle exceptional cases; additional inputs and outputs are added, for instance to ease maintenance of the final product.Besides the modeling activities themselves, the process consists of the following activities:•Simulation: Model executability is the basis of the main validation technique employed in our incremental process [7]. Together with the customer, exemplary system runs are produced that demonstrate the model essentially operates according to the customer’s re-quirements.Simulation is not restricted to interactive step-by-step executions. Using advanced sym-bolic execution techniques based on constraint-logic-programming, it is possible to auto-matically derive simulation runs from abstract test case specifications; a test case specifi-cation typically demands that the model is brought into a certain state (functional tests) or that every transition is executed at least once (structural tests).•Analysis: While simulation is helpful to determine that the system indeed fulfils its re-quirements, there are some questions related to quality assurance that cannot be answered by simulation alone, since simulation gives answers only about single system runs, not about all possible system runs (mathematically, simulation shows existential properties, not universal ones). Some typical questions are whether the model is deterministic (i.e., for each input from the system environment there is at most one possible output specified) and complete (i.e., for each input from the system environment there is at least one possi-ble output specified). The AutoFocus toolset includes analysis tools that help to answer such questions. It also includes verification tools such as model checkers [9], which are used for mathematical proofs of critical system properties. Since such proofs are very ex-pensive (in terms of time, effort and required expertise of the tool user), the use of verifi-cation tools must be carefully judged against the economic risk of system malfunctions.•Refactoring: An obvious problem with any incremental system development process is that the resulting system specification may be cluttered and hard to understand, as itsstructure is determined partly by the order in which the increments occurred. Extreme programming makes use of elaborated refactoring [6] patterns to clean up the system after each increment so that it is both easier to understand and more amenable to further incre-ments. Similar techniques can be used for executable models; however, this is still an ac-tive area of research.To summarize, we advocate a development process that consists of several iterations where at the end of each loop, instead of hand-written code an executable system model is presented to the customer. This approach is similar to Extreme Programming, but focuses on a more abstract modeling of the system rather than its implementation. In contrast with Extreme Programming, however, production of the final code is deferred until the end of the development process. From Models to ProductsOnce the model is considered to be sufficiently correct and detailed, it is used as the basis for the production of the target code. For the target code, too, quality assurance must be performed. As the resulting code is likely not amenable to automatic analysis, the core activity here is testing (see, e.g., [10]). Essentially, there are two approaches:•The target code is produced by hand. This is a typical situation for customer/supplier re-lationships, where the model serves as the software specification of the final product. In this case, the code produced by the supplier must be tested to ensure its conformity with the model. It is possible to automatically derive test sequences for the implementation from simulation runs, in particular from the runs produced by symbolic execution as mentioned above.•The target code is produced by an automatic code generator. While in principle it is pos-sible to mathematically verify code generators, in practice there is still some risk (albeit a very small one) that the code generator produces incorrect code. Thus, even for automati-cally generated code it is prudent to test the code. For avionics systems, rigorous testing is even required: Standards such as DO-178B require, among other points, tests with clear code coverage criteria (MC/DC); it is not sufficient to have coverage only on the models. In both cases, however, additional tests must be performed to ensure that the model is not based on incorrect assumptions about the interaction with the environment, which could lead to timing problems and race conditions. Such tests can be performed by Hardware-in-the-loop approaches. Example: A Digital WatchAs an example of the description techniques of AutoFocus, this section presents parts of a model for a digital watch. The watch has three buttons (T1, T2, T3) that are used to change the display mode (date, time, stopwatch) and to set the current time and date after a battery change. Fig. 3 shows the top-level structure diagram of the watch model.The data types of the channels are defined using Data Type Definitions (DTDs) as follows: data Signal = Present;data Segments = Date(Int,Int,Int,Int,Int,Int)| Time(Int,Int,Int,Int,Int,Int)| Stop(Int,Int,Int,Int,Int,Int);Fig. 3. Top-Level View of the WatchDeeper in the modeling hierarchy, the watch component contains a time component that com-putes the time of day from internally derived signals (hs, zs) that hold the time of day in 1/100s and 1/10s; they are derived from an internal counter. There are other components to keep track of the current date and to model the stopwatch function.The time component (see Fig. 4) is quite complex, because it is also responsible for the adjust-ment of the time by the user. It has separate components to compute the segment digits for the display (Sec1, Sec10, Min1, Min10 and H12); depending on the current display mode they either display the relevant part of the current time, or the current time setting when the watch owner changes the time.Fig. 4. Component Network inside the Time Component of the WatchNote that in the diagram there are two kinds of channel connectors: Delayed channels (marked with a circle) and immediate channels (marked with a diamond). Messages sent through an im-mediate channel are visible to the receiver in the same reaction; messages sent through a delayed channel are visible in the following reaction. There are some subtle methodical issues involved intheir use. Generally, immediate channels should be used for the data flow within an embedded controller. Without immediate channels it would not be possible to switch from 23:59:59 to 00:00:00 within one model reaction, because the overflow-values would be present only in the next time step. On the other hand, for mathematical reasons every communication cycle in the system must contain at least one delayed channel.Fig. 5 shows the behavior of the component Setting as an example for state transition diagram. It describes the way to set the time using the signals T1, T2, T3 and the current mode that is com-puted by another component of the model (the mode signal is also computed from the three but-tons, but it is handled separately for reasons of modularity). For example, incrementing the min-utes display is modeled with the transition T2?P; T3?; IncM1!Present which connects the state Minute1 to itself. The semantics of this transition is as follows: When button T3 is not pressed, but button T2 is, then send the signal Present to the minute segment component.Fig. 5. State Transition Diagram of the Setting ComponentIn addition to input and output statements transitions can be annotated with preconditions (which are predicates over local variables and values read from input channels) and actions (which are assignments to local variables). Together with the DTD specifications, this allow models that are completely independent from the target programming language. This is important for reusing the models for other targets (for example with a different processor and a different instruction set). While the model itself is not very ambitious, its implementation is, since the resources of the watch are severely limited (4bit processor, 2KB of memory). The model is indeed the basis of a watch implementation with an industrial partner, but we did not yet implement a code generator for the assembly language used in the project. Given the rigorous semantics of AutoFocus, which is very close to the description techniques, and the limited size of the watch model, it is still man-ageable to translate the model into assembly language by hand.The code that results from the watch model is not used stand-alone; it is linked with a number of arithmetic and I/O libraries.Extensions for Real-TimeWith the description techniques presented so far, models describe the functionality of the system under development in terms of input/output reactions. For the final implementation, in addition tothe functionality, timing requirements must be considered. They relate system executions with the physical time of the system’s environment. Typical timing requirements are stated as separa-tion requirements (two inputs or outputs must be separated by at least a certain duration), or as proximity requirements (two inputs or outputs must be separated by at most a certain duration). Timing requirements fulfill two purposes: They impose demands on the maximal execution time for an input/output reaction of the system (and thus on the performance of the target hardware), and they state assumptions on the duration of activities of the controlled hardware.Timing requirements can be concisely specified by annotated Message Sequence Charts. Fig. 6 shows a simple timing requirements for the watch: It states that the watch, when switched to date mode by pressing button T3, displays the date for three seconds (rather, any number of display messages are sent to the hardware until exactly 3 seconds have passed) and then returns to time mode. This requirement is a combination of proximity and separation requirement. Further (quite trivial) requirements specify that a second (rather, 1/100s) of model time corresponds to a second of real time.Fig. 6. Timing Requirements in a Message Sequence Chart (MSC) Obviously, the relationship between model time and real time must be verified. Currently, this is done by hand-written test cases, which measure controller execution time and environment re-sponse times. A more automatic scheme will translate time-annotated MSCs like the one above into special time observer components. These components run in parallel to a standard hardware-in-the-loop setup (see Fig. 7) and give verdicts on the satisfaction of timing requirements for notFig. 7.ConclusionThis paper touches only some of the issues of model-based development. While the classical ar-eas of CASE tools (description techniques and code generators) are quite stable in our toolset, the validation and verification tools are still undergoing development and field studies with our part-ners and customers. In particular, the promising field of model-based test case generation is making rapid progress. In order to cover not only the later phases of system design, but also re-quirements analysis, the AutoFocus toolset has been connected to the requirements management tool DOORS [1].Acknowledgment. Peter Braun, Heiko Lötzbeyer, Alexander Pretschner and Dr. Bernhard Schätz, our colleagues from TU München, have contributed greatly to our understanding of model-based development and to the AutoFocus toolset itself.References1. B. Bajraktari: Modellbasiertes Requirements Tracing. Master thesis, TU München, 2001.2.K. Beck: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.3. B.W. Boehm: A spiral model for software development and enhancement. Software Engi-neering Notes, 11(4), 1994.4.G. Booch, I. Jacobson, J. Rumbaugh: The Unified Modeling Language User Guide. Addison-Wesley, 1998.5.M. Broy, O. Slotosch: Enriching the Software Development Process by Formal Methods,Proceedings of FM-Trends 98, LNCS 1641.6.M. Fowler: Refactoring. Improving the Design of Existing Code. Addison-Wesley, 1999.7. F. Huber, S. Molterer, A. Rausch, B. Schätz, M. Sihling, O. Slotosch: Tool supported Speci-fication and Simulation of Distributed Systems, Proceedings of International Symposium on Software Engineering for Parallel and Distributed Systems, 1998.8. F. Huber, B. Schätz: Integrated Development of Embedded Systems with AutoFOCUS.Technical Report TUM-I0107, Fakultät für Informatik, TU München, 2001.9.J. Philipps, O. Slotosch: The Quest for Correct Systems: Model Checking of Diagrams andDatatypes, P roceedings of Asia Pacific Software Engineering Conference 1999, 449-458. 10.A. Pretschner, O. Slotosch, H. Lötzbeyer, E. Aiglstorfer, S. Kriebel: Model Based Testing forReal: The Inhouse Card Case Study in Proc. 6th Intl. Workshop on Formal Methods for In-dustrial Critical Systems (FMICS01), Paris, July 2001.11.S. Prowell, C. Trammell, R. Linger, J. Poore: Cleanroom Software Engineering. Addison-Wesley, 1999.12.G. Wimmel, A. Pretschner, O. Slotosch: Specification Based Test Sequence Generation withPropositional Logic, Journal on Software Testing Verification and Reliability (to appear).。

基于模型驱动的实时嵌入式系统赵勇;陈香兰【摘要】随着实时嵌入式系统的功能越来越复杂,现有的软硬件分离、软硬件协调等实时系统设计方法已经无法满足其系统实现的要求.本文根据模型驱动开发架构MDA和模型集成开发MIC的核心思想,将时间语义结合服务体/执行流(Servant/Exe-Flow Model,简称SEFM)模型,提出了一种基于模型驱动的实时系统设计方法.首先,本文给出了SEFM模型的元模型表达系统的抽象语义,同时使用XML语言和框图语言来描述SEFM模型的具体语法.结合XML解析技术,根据同一抽象语法的不同具体语法能够相互转化,实现了框图语言的代码生成,最后以实时跟车系统设计方案表明该系统实现方法的可行性和正确性.%As the real-time embedded systems are more and more complex,the existing RTOS design method,such as hardware and software separation,hardware and software coordination and so on,is unable to meet the requirements of its bined with the core idea of MDA and MIC,this paper proposes a method based on model-driven for the RTOS design,which combines the temporal semantics with the Servant / Exe-FlowModel.Firstly,the paper gives the abstract semantics of the meta model expressing SEFM,and describes the concrete syntax of SEFM using XML language and block diagram language.If a different specific syntax can express the same abstract syntax,then each of them can be transformed into the bined with XML parsing technology,the code generation of SEFM can be realized.Finally,the experiments of thefollowing vehicle system show that the method of system design is feasible and correct.【期刊名称】《计算机系统应用》【年(卷),期】2017(026)008【总页数】5页(P83-87)【关键词】实时;嵌入式;MDA;MIC;SEFM【作者】赵勇;陈香兰【作者单位】中国科学技术大学计算机学院,合肥230026;中国科学技术大学计算机学院,合肥230026【正文语种】中文嵌入式系统是以应用为中心,以计算机技术为基础,软硬件可裁剪,适应应用系统对功能、功耗、可靠性、体积、成本严格要求的专用计算机系统[1]. 当前嵌入式系统已被广泛地应用到航天航空、工业控制、消费类电子产品等领域,嵌入式系统设计也变得越来越复杂,一般会涉及硬件与软件,以及功能和时间等多个方面的要求.传统的嵌入式系统设计方法已经无法满足复杂嵌入式系统的设计需求了,主要表现在以下几个方面:(1)软硬件分离的设计方法,只能实现软硬件性能的各自优化,无法达到系统的整体性能最优. (2)软硬件协同设计方法对系统开发者提出了很高的要求——对系统统的软件和硬件熟悉程度到了苛刻的要求. (3)嵌入式系统不仅功能变得越来越复杂,而且对系统完成这些功能的响应时间也提出了更为严格的要求.近年来,随着软件工程和系统模型技术的发展,模型驱动开发的系统设计理念被越来越多的系统开发人员认可和使用. 模型驱动系统软件开发是对现实世界建立模型、转换模型,直到生成可执行代码. 在模型驱动系统开发过程中,模型是软件开发的核心. 软件的开发和更新过程就是以模型为载体,通过模型之间的映射机制来驱动的过程,也可以认为是高抽象级模型向低抽象级模型的逐层转化和实现的过程.2002年,对象管理组织OMG(object management group)提出了模型驱动架构MDA(Model Driven Architecture). MDA结合面向对象技术,利用统一建模语言UML对系统进行分析建模,再通过模型得到代码. MDA提倡将模型作为核心,贯穿于系统设计的整个开发周期,用模型描述系统的需求、设计、测试、维护等过程. 但是,MDA作为一个通用的软件开发标准,缺乏面向领域开发的支持. 范德堡大学的Janos Sztipanovits和Gabor Karsai提出了模型集成计算MIC(Model-Integrated Computing). MIC是一种以模型为中心的软件系统开发理论,其模型分为4个层次,从上到下依次为元元模型层、元模型层、模型层以及实现层.在嵌入式领域中,MIC已经得到广泛关注和应用. 目前,MIC在嵌入式系统的模型研究更多地局限于功能的设计,而缺乏时间语义的支持.本文在深入研究MDA和MIC方法的基础上,将时间语义结合SEFM模型,提出了一种基于模型驱动架构的实时嵌入式系统设计方法,重点表述了层次间模型的映射转化和代码生成的设计,最后以跟车系统案例建模仿真实现加以说明本设计方法的可行性和有效性.前面提到,传统的嵌入式实时系统设计的不足之处是,高层次的抽象阶段与目标环境中的开发编程阶段脱节. 这是因为各个抽象层次之间的映射关系不明确,高层次的应用抽象描述无法直接映射成抽象模型,抽象模型也无法直接转化成代码. 实际的系统设计还需要手动编写代码,系统的功能特性和时间特性都是经过代码的某种组合才能完成,这个过程是艰难而容易出错的.本文将嵌入式系统按照设计阶段分为5个层次.如图1所示,从上到下依次是应用描述层,抽象模型层,编程语言层,可执行代码层,硬件层. 模型驱动开发关键在于最上面的三个层次的研究,应用描述层位于整个开发过程的最顶层,它定义了模型的建模元素,一般是一种领域无关的通用模型描述语言. 该层不仅需要描述整个系统的行为,而且需要分析和验证系统,为后续开发打下基础. 抽象模型层采用领域内抽象模型对嵌入式实时系统进行抽象描述和刻画. 利用仿真平台对整个系统或局部系统进行仿真,并观察仿真结果. 当系统满足设计要求时,将领域抽象模型变换成代码. 最后,结合硬件平台代码,使用嵌入式集成开发工具,将生成的可执行软件代码移植到相关的硬件平台,完成系统实现.在实时嵌入式领域中,系统行为的正确性不仅取决于计算的逻辑结果,而且与产生这些结果的物理时间有关. 传统的实时系统模型无法保障任务释放时间的确定性,尽管可以通过反复测试使得系统具有可靠性,但这种方法存在缺陷,其根本原因在于: 实时系统模型中缺乏明确描述时间属性的语义.中国科学技术大学龚育昌教授等人提出了执行流/服务体(SEFM)模型,并在此基础上进行了时间可预测实时模型的深入研究. 执行流是对CPU执行能力的抽象,每个CPU对应一个执行流抽象; 服务(Service)是最基本的功能单元,也是调度的单位,任务由一组服务组合而成,服务描述了任务间的交互方式以及各任务的时间属性.根据MDA和MIC方法提出的元模型思想,可使用元模型刻画SEFM最核心的语义,也就是SEFM的抽象语法. 在元模型的基础上再实现时间约束和服务体组件刻画,可实现多种语言来描述SEFM的具体语法. 这样基于相同抽象语法的具体语法的不用语言可以实现相互转化.编程语言的语法和语义有着很重要的区别,语法为构造有效语言制定规则,语义则表示语言的含义. 模型也有着类似的区别,语法为模型如何表示制定规则,语义则表示模型意味着什么含义.模型的抽象语法代表着模型的结构,比如模型可以使用图的结构表示,由点和边构成,边连接着点. 或者使用树结构表示,可以定义层次结构. 相比较而言,模型的具体语法表达抽象语法的特殊符号,如框图语言. 具体语法代表的所有结构集合能够用来表示模型的抽象语法. 也就是抽象语法包含了模型的抽象结构,具体语法提供文本或者图描述模型.抽象语法比具体语法更加基础,如果针对同一个抽象语法表达的两个具体语法,那么一个转化成另一个往往是容易的. 通常,元模型是一种模型的建模语言或符号. 在建模过程中,工程师经常使用元模型来精确定义抽象语法. 元模型形式化地定义了语言的各种组成元素以及它们的抽象语法. 在MDA和MIC中,元模型一般使用UML类图表示. SEFM模型的UML元模型如图2.SEFM模型中的每个组件都是NamedObj类的实例. NamedObj有四个子类,分别是属性Parameter、实体Entities、端口Port和关系Relation. SEFM模型由顶层实例包含其他实例组成,这些实例通过端口进行交互. 所有的对象(实例,端口,关系)都可以分配属性,用来定义参数或者注释. 端口间通过链接来确定关系,表示元模型中关系类和端口类之间的关联关系.上文提到,具体语法是抽象语法的更高层次描述.抽象语法是定义数据结构来表示模型,具体语法则是捕获如何呈现机器间通信或与人类交互. 具体语法一般可使用编程语言表示,常用的替代具体语法的语言是可扩展标记语言XML. 从常见的元模型可以推导出建模语言的可视化语法,也可以是文档类型定义或XML文档. 每个元素的图形语言将对应于一个XML文件元素. 比如使用图形符号的输入端口IP0对应XML文件元素＜inputport name=IP0＞.区别模型的抽象语法和具体语法对于建模技术会产生一个深远的影响: 编辑和操作. 建模者与具体语法进行交互: 使用具体语法的“原始”概念来创建和修改模型结构. 如果开发环境是图形化的,那么开发人员可以直接对图形对象进行操作. 这些图形对象只是底层抽象语法对象的渲染; 因此,图形对象的变化将导致底层对象的更改.随着高层次抽象模型的发展,基于模型的代码生成技术(Model-Based CodeGeneration,简称MBDG)成为一个新的研究领域. 代码生成的核心思想就是将模型的建模语言转化成可执行语言. 代码生成能够从设计的模型中有效的综合实现代码. 理想情况下,在系统的设计阶段,代码生成可以实现模型在不同平台下的实现.生成编码社区(GPCE)着重推广了一种基于模板的元编程技术,编译器工具如AspectJ和AHEAD为这种编程范例提供标准,涉及模板语言、源建模语言的元模型的使用和目标语言和平台的描述. 基于模板的元编程技术采用一种编程语言操纵其他编程语言完成代码生成. 操纵语言称为元语言,被操纵语言称为对象语言. 对象语言使用模板作为语言的第一对象数据,在编译时模板会被解释为平台相关的可执行语言. 通过对基于模板的元编程技术研究,本文模型的代码生成思想如图4所示,代码生成过程可以等价为一个模型转换,它为模型生成其他平台语言提供了规范,呈现相同模型的不同语法实现,同时保留了模型的抽象语义.实时嵌入式系统一般使用C语言编写功能代码,本文也采用C语言作为对象语言,也就是模板. C语言模板是一个.c文件,这样可以保证文件的结构唯一. 适配器是代码生成框架的关键抽象,每个模型组件都与一个适配器. 为了实现可读性和可维护性的适配器,目标代码块的适配器被放置在同一目录下的不同文件中.对于每个适配器来说,对象代码包含的代码模板文件都是人工手写的,并且已经验证了代码的正确性(即语言功能上等价于SEFM模型组件). 代码模型存储在代码库中,针对相同模型的代码生成来说,代码模型是可重用的. 手动编写模板还保留了生成代码的可读性,同时使用宏处理组件实例的具有信息(如端口信息,参数变量等).本文提出的模型系统设计方法是面向框图语言、并行计算和仿真等技术在嵌入式系统设计中的综合应用,该方法将模型驱动架构的核心思想贯穿整个系统设计的全过程.如图5所示,是基于模型驱动的实时嵌入式系统方法实现框架. 在应用问题层使用框图语言来描述系统的功能属性,使用逻辑时间(时间戳)的语义来描述系统的时间属性.使用时间戳的时间语义可以有效的支持系统各个簇之间的事件同步和时间同步. 通过建模可以得到仿真的结果,如果仿真结果能够达到预期目标,利用代码生成技术,就可以生成相应的功能代码了.结合WCET和调度器算法分析功能代码的可调度性.如果产生的功能代码,不满足可调度性,就需要重新建模,直到产生的功能代码满足可调度性. 将功能代码和系统代码链接在一起,通过编译器写入到相关硬件.本文用两种方案实现了实时跟车系统: 1)使用SEFM模型实现,如图6所示; 2)在μC OS上进行实现.响应时间是衡量实时系统性能的一个重要指标,表1显示了不同方案中任务实际响应时间与实际需求时间的统计结果. 从实验结果可以看出SEFM能够较好的满足实际的时间需求,波动较小. 其主要原因是因为模型驱动在系统设计整个过程始终将功能和时间紧密的结合,确保模型映射和转换过程中,时间语义不发生改变,同时,也不随着硬件平台的变化而变化.本文结合MDA和MIC的模型驱动思想,将时间语义结合SEFM模型,提出了一种基于模型驱动架构的实时嵌入式系统设计方法. 将系统的功能设计和时间设计贯穿整个实时系统实现的全部过程. 使用元模型来表达SEFM的抽象语义,XML语义和框图语言来表达SEFM的具体语言,这样的设计可以确保系统在转化过程中语义的不变. 通过实验发现,这样的设计能够确保系统在实际运行时的物理时间满足系统需求.目前,建模平台功能比较单一,需要进一步完善建模平台的建模仿真功能.【相关文献】1Schirner G,Götz M,Rettberg A,et al. Embedded systems:Design,analysis and verification. Berlin Heidelberg:Springer,2013.2Henzinger TA,Sifakis J. The embedded systems design challenge. International Symposium on Formal Methods.Berlin Heidelberg,Germany. 2006. 1–15.3Miller J,Mukerji J,Belaunde M. MDA Guide V1.0.1. Object Management Group,2003.4Völter M,Stahl T,Bettin J,et al. Model-driven software development:Technology,engineering,management. New York: John Wiley & Sons,2013.5Sztipanovits J,Karsai G. Model-integrated puter,1997,30(4): 110–111. [doi: 10.1109/2.585163]6Iacovella CR,Varga G,Sallai J,et al. A model-integrated computing approach to nanomaterials simulation. Theoretical Chemistry Accounts,2013,132: 1315. [doi:10.1007/s00214-012-1315-7]7Atkinson C,Kühne T. Model-driven development: A metamodeling foundation. IEEE Software,2003,20(5):36–41. [doi: 10.1109/MS.2003.1231149]8Lee I,Leung JYT,Son SH. Handbook of real-time and embedded systems. Florida: CRC Press,2007.9Krahn H,Rumpe B,Völkel S. Roles in software development using domain specific modeling languages.Proc. of the 6th OOPSLA Workshop on Domain-Specific Modeling (DSM‘ 06). Portland,Oregon,USA,2014.10龚育昌,张晔,李曦,等. 一种新型的构件化操作系统的内核设计. 小型微型计算机系统,2009,30(1): 1–7.11吴明桥,陈香兰,张晔,等. 一种基于服务体/执行流的新型操作系统构造模型. 中国科学技术大学学报,2006,36(2):230–236.12Zhou Y,Lee EA. Causality interfaces for actor networks.ACM Trans. Embedded Computing Systems (TECS),2008,7(3): 29.13Jensen JC. Elements of model-based design. University of California,Berkeley,Technical Memorandum. UCB/EECS-2010-19,2010.14Ptolemaeus C. System design,modeling,and simulation:Using ptolemy II. Berkeley: Ptolemy,2014.15Marwedel P,Goossens G. Code generation for embedded processors. US: Springer Science & Business Media,2002.16Rajamani R,Choi SB,Law BK,et al. Design and experimental implementation of longitudinal control for a platoon of automated vehicles. Journal of Dynamic Systems,Measurement,and Control,2000,122(3): 470–476. [doi:10.1115/1.1286682]。

A UML Virtual Machine for Embedded SystemsTim Schattkowsky, Wolfgang MuellerC-LAB, Paderborn University{tim|wolfgang}@c-lab.deAbstractStateCharts are well accepted for embedded systems specification for various applications. However, for the specification of complex systems they have several limitations. In this article, we present a novel approach to efficiently execute an UML 2.0 subset for embedded real-time systems implementation with focus on hardware interrupts, software exceptions, and timeouts. We introduce a UML Virtual Machine, which directly executes sequence diagrams, which are embedded into hierarchically structured state transition diagrams. Whereas state diagrams are directly executed as Embedded State Machines (ESMs), sequence diagrams are translated into UVM Bytecode. The final UVM execution is performed by the interaction of the ESM and the Bytecode Interpreter. Due to our completely model-based approach, the UVM runtime kernel is easily adaptable and scalable to different scheduling and memory management strategies.Keywords: UML, Executable Models, Hardware/Software Co-design, Virtual Machine, Embedded Systems1.IntroductionEmbedded systems design comes in different variations and is most often due to the specific application or project [7]. Sometimes, graphical means like StateCharts or Matlab/Simulink are applied for graphical specification. The different tools come with different plugins for code generation. Different code generators for different micro controllers such as C166 and different Real-Time Operating Systems (RTOSs) like OSEK are available [6]. There have been efforts to investigate retargetable compilers to easily adopt them to different hardware platforms [4]. Other investigations concern different scheduling and timing analysis technologies [3]. Most recently, the Model-Driven Architecture (MDA) approach [14] became also recognized in the domain embedded systems design. MDA is based on the idea that specification and development is based on a platform-independent model (PIM). The PIM has to be mapped to a platform-specific model (PSM) in some undefined way. This PSM is used for the actual implementation. Executable UML seems to become a major role here, as it enables the PSM itself to be executable. However, current approaches mostly target towards platform-specific code generation. In addition, they the limitations and real-time requirements of embedded systems are not considered.A different approach to portable code comes from the idea of using a Virtual Machine (VM). A VM is a virtual computer defining the runtime environment for the executed software. Thus, the VM functions as a low level abstraction layer defined by its behavior and the format of the executed software program. The VM programs consist often of bytecode similar to the machine code executed by a microprocessor. Examples for the use of bytecode are the P-Code used by UCSD Pascal and the Java Bytecode. One of the main advantages of a VM is the portability of the code. Once the VM is ported to a specific platform, any available bytecode should instantly run on that VM. Any VM improvement with respect to runtime, stability, and security is immediately beneficial to existing software. This highly reduces costs for development and testing.We introduce a novel approach to efficiently execute an UML 2.0 subset for embedded microcontrollers. In order to support real-time system implementation our approach explicitly focus on hardware interrupts, software exceptions, and timeouts. For efficient execution, we define a UML virtual machine, which directly executes UML 2.0 [16] state diagrams and embedded sequence diagrams. The combination of both overcomes the limitations of purely state-oriented modeling means. The computation of UVM is defined by the close interaction of the ESM (Executable State Machine) Interpreter and the Bytecode interpreter. The first one processes direct binary representation of state diagrams whereas the second one manages the execution of the Bytecode, which is generated from the embedded sequence diagrams. The UVM execution starts from an initial ESM, the Adaptive Runtime Kernel, which controls scheduling and memory management of the different ESMs. Since our approach is completely model-based, the kernel and it subcomponents (scheduler, memory manager, ESM loader) are implemented as ESMs, so that the kernel can be easilyreconfigured by reloading application-specific schedulers or memory managers, respectively.The paper is structured as follows. The next section discusses related works. Section 3 introduces our executable UML 2.0 subset combining state and sequence diagrams to executable models. Section 4 the UVM architecture and its components as well as the UVM Bytecode. Section 5 provides a detailed example before Section 6 closes with conclusions.2.Related WorksWith respect to embedded systems design methodologies, there are very few approaches, which are frequently applied for real systems like the one from IMEC, COSYMA, OCTOPUS [7], or the SpecC methodology [2] . All except OCTOPUS are based on specific design environments and/or languages. OCTOPUS was one of the first methodologies, which followed a straight object-oriented approach including HW/SW partitioning already considering a hardware abstraction layer (hardware wrapper).Meanwhile, in the context of the OMG Model Driven Architecture [14], the notion of executable UML became of wider interest [10]. Based on Starr’s approach to executable UML [13], which is mainly based on class and state diagrams, Project Technology developed X T UML [9] as an executable and translatable UML subset for embedded real-time systems in the areas of flight-critical systems, performance-critical and fault-tolerant telecom systems, and resource-constrained consumer electronics. The corresponding tool integrates a plugin-interface to adopt different code generators. A similar approach to executable UML is xUML [17] which also relies on a language-specific code generation, e.g., for Ada or C [15].The most prominent approach to portable code was introduced by Java and its VM [5]. Though Java was originally designed for embedded systems, due to the large footprint of its runtime environment and the garbage collection memory management, it is less suited for small micro controllers and real-time applications. The Java compiler generates low-level bytecode, which is executed on a Java Virtual Machine (VM). Therefore, the compiled Java program runs on each platform where a Java VM is available.There also exists a proposal for a UML VM [12]. However, this does not cover the use of a true VM for UML models. Instead, the authors present in their approach mainly a Java data model for representing the four-layer metamodel of the UML. To allow the executionof a model by an interpreter, the authors mainly attach state diagrams to classes. Detailed behavior has to be implemented manually in Java.Our approach presents a VM designed to directly execute UML models. The underlying design methodology resembles the structure of well-established concepts for embedded system specification by using an executable UML 2.0 subset. In contrast to other approaches, our concepts combine a completely model-based approach focusing on the specific requirements of embedded systems including interrupts and timeouts.3.MethodologyStateCharts are frequently applied in embedded systems design. UML has introduced the State Transition Diagrams (STDs, also known as StateMachine Diagrams) as a variation of Harel’s StateCharts [1]. However, several behavioral aspects like concurrent objects and simple data-oriented algorithms (e.g., sorting) cannot be easily expressed. The UML 2.0 sequence diagrams (SDs) have several extensions for loops etc, which make them an ideal compliment for the use of STDs. We can overcome these drawbacks of using STDs through the integration of SDs with STDs.Our approach enables object-oriented development using STDs and SDs for the specification and execution of real-time embedded systems. We cover interrupt/exception handling and hard real-time constraints through timeouts since they are of key importance for safety and reliability [3]. The remainder of this paper focuses on the use of SDs and STDs in our approach, since the use of class diagrams for type definition is quite straightforward.In our approach, an STD describes behavior of a method (Operation) at the topmost level. This enables state-oriented modeling within an object-oriented system and is crucial for the integration with existing designs. Furthermore, it enables consistent declarative timeout-, interrupt- and exception handling. Such exceptions may include software exceptions like runtime exceptions and user-defined exceptions as well as external exception, i.e., interrupts.We support STDs consisting of composite and simple states. Concurrent States are intentionally unsupported, as we support concurrency through asynchronous operation calls. However, introducing an operation for each region of a concurrent State and interconnecting these with communication channel objects can resemble concurrent States. These Operations can then be run concurrently. However, additional synchronization may be necessary to resemble the semantics of a concurrent State.State transitions are triggered by different events. In our approach, these are state completion, explicit, timeout, hardware interrupt, and software exception, i.e., division by zero. Interrupts and exceptions are processed immediately and cause the current state to be exited. Thewhole Operation is completed when the associated state machine reaches a final state.In our approach, an integration mechanism is provided to incorporate additional Events from an Operation. Each StateMachine may have an attached EventGenerator Operation, which can produce additional EventObjects. The EventObject Class defines a member operation that can be used to retrieve the actual event identifier as an integer. Additionally, an action Operation can be assigned, that will be called for all compatible actions on transitions within the StateMachine. Together, this allows having individual action/event semantics per StateMachine and enables a much broader use of StateMachines than other approaches. Finally, it enables the reuse of existing state charts in our methodology. In this context, care has to be taken as the execution semantics may differ.The SDs used in our approach have a limited set of necessary features compared to what is allowed by the UML 2.0 specification (cf. Figure 3). This reflects the properties of the supposed execution environment. All messages in the diagrams have to be synchronous. The CombinedFragment as defined in UML 2.0 is used to resemble control structures. Thus, in our approach it is limited to be an Alternative, Option, or Loop.The STDs hierarchically embed STDs (StateMachines) and/or SDs (Interactions), which may again integrate other STDs or SDs (Behaviour as in the UML metamodel). Which combination of diagrams is used is mainly due to the individual application and system’s complexity. To achieve the arbitrary composition of both diagrams, we had to define interfaces between sequential parts represented as UML sequence and state diagrams. Those interfaces allow the integration of both into composite models.When integrating a SD into a STD, the SD has to expose state-like behavioral semantics. The sequential end of the sequence diagram is equivalent to a completion transition. Furthermore, SDs can directly trigger transitions in the containing StateMachine. In the model, this is depicted by a call to the transition() operation of the Runtime class. Finally, exceptions raised by the sequence diagram have to consistently map to transitions in the containing state machine.4.The UML Virtual MachineThe UML Virtual Machine (UVM) is a virtual computer for executing UML models based on our approach using the previously introduced combination of STDs and SDs. In order to enable simple and efficient execution of such models, we use a transformation to equivalent executable state-oriented binary models. A StateMachine from an STD is translated to the binary encoding of an Executable State Machine (ESM). An embedded SD defining an Activity of a State or Transition is translated to executable UVM bytecode.The next section outlines the UVM basic principles. Thereafter, we introduce Executable State Machine (ESM) and bytecode details.4.1UVM ExecutionThe UVM consists of two major components: the Model Execution Unit (MEU) and the Runtime Kernel (RK) (see Figure 1).Figure 1. UML Virtual Machine ArchitectureThe MEU executes the RK and the UML models, i.e., STDs and the embedded SDs. The MEU thus has two interacting interpreters, one for the Executable State Machine (ESM) generated from an STD and another one for the Bytecode compiled from an SD.The ESM Interpreter keeps track of the current state and performs transitions between States. After a Transition, it invokes the Bytecode Interpreter to execute the Activity associated with the current state and waits until this Activity finishes or an interrupt or timeout occurs. The Bytecode Interpreter executes the Bytecode in a microprocessor-like manner using an instruction pointer and a stack for program control. However, stack frames also include State information.A Timer in the MEU enforces Timeouts. The ESM interpreter manages such timeouts just like interrupts from external sources and unexpected Exceptions (i.e, ‘division by zero’ or exceptions from the host platform). Such events are mapped to the respective Triggers in the ESM. In such a case, the ESM Interpreter immediately stops the Bytecode Interpreter and the current state is pushed to thestack while the ESM Interpreter switches to a transition for handling the event and gives control to the Bytecode Interpreter for executing the Bytecode of the Activity.Nested external interrupts from the environment, like from a sensor, are processed corresponding to traditional interrupts by firing the corresponding event when the current interrupt processing has finished. Note here, that the sequence of multiple different interrupts is not preserved and the multiple occurrence of an interrupt may result in a single event.As introduced in the previous section, the UVM is based on the execution a hierarchical StateMachine. Thus, an initial model has to be provided. That initial machine is denoted as the Adaptive Runtime Kernel (ARK) und is contained in predefined operations of special class. The ARK implements the basic runtime environment of the UVM like memory manager, scheduler, and the (optional) dynamic ESM loader.Since the ARK is implemented along the concepts of a hierarchical ESM itself, it can be easily adapted to the individual application. The ARK scheduler and the memory manager control the different applications given as ESMs. The memory manager is implemented as a set of operations on the ARK class that perform the actual allocation and deallocation. Those operations are invoked by the Bytecode Interpreter whenever object instances are created and destroyed. The scheduler is implemented as an operation computing the next model to be scheduled for execution. The scheduler implementation is likely to rely on external events (i.e., timer interrupts) for its implementation. Through this, different algorithms can be adapted for both functionalities to achieve the desired real-time properties. In the simplest case, only has to manage one ESM, which gives a trivial implementation of the scheduler. Simple implementations for the management of multiple ESMs can be given by round-robin scheduling and buddy-style memory management.4.2Executable StateMachinesAs introduced before, the STD StateMachine is translated to an equivalent Executable StateMachine (ESM) that is based on a simplified metamodel where States have only a doActivity and Transitions have no Activities at all and just a single Trigger. The design model will be transformed accordingly by introducing additional States and Transitions to resemble the defined behavior. This is also used to resolve deferred Triggers and conflicting Transitions. Consequently, there is no need for an event queue at runtime, as at most one transition can be enabled by an event. This simplifies the UVM implementation, as the handling of conflicting events is one of the most critical issues when executing StateChart variants, as it is usually complex and has several semantic variants.Furthermore, each state may have a timeout value. This value is derived from the transition timeouts for the state in the design model. As there may be multiple transitions containing expressions, these expressions will be combined and evaluated when entering the state to compute a definitive timeout value. If that timeout is less then the pending timeout (from an embedded state), it is pushed on the UVM timeout stack and becomes the pending timeout. A timer in the UVM triggers the corresponding transition if the state is not exited before the timeout. The timeout is finally removed from the timeout stack when the state is exited, e.g., by completion.4.3UVM BytecodeAs introduced before, the encoding of an SD results in Bytecode, which is equivalent to statements of the SD. This Bytecode is created based on the instruction set of the UVM. However, since the SD may include severally nested expressions and invocations, those have to be resolved and mapped to the instruction set. The code of the nested diagrams is transformed by decomposition of the expressions into an equivalent flattened version composed of executable UVM instructions. Parameters are passed to and from Interactions through a stack, like it is given in other compiled high-level languages. Table 1 gives an overview of the most important instructions.As a basic concept, the UVM has no registers, as this implies several limitations. However, UVM hardware implementations could make transparent use of registers to optimize their performance. In general, the lack of registers allows flexible use of the available hardware resources and enables simple scalable implementation in both hard- and software.The UVM instruction set has instructions similar to those of common microprocessors. The syntax is derived from the Motorola syntax [11], as the explicit operand size declaration is convenient for the register-free approach. Most instructions in the UVM equal their counterparts in common microprocessor instruction sets like those of the Intel x86 family and Motorola 68k family (see Table 1). This includes the typical instructions for moving data, integer and floating point math and bit manipulations. The UVM directly supports classes and primitive types. We support the Boolean type, 32-bit Integers, Strings (as byte arrays), and 64 bit Floating-Point Numbers.Furthermore, the control instructions differ to reflect the ESM approach. Instructions for managing and invoking objects are introduced. In addition, instructions for state transitions are required. Unconditional branches are not available, as these are not possible at the model level. Subroutine calls remain, but are interpreted asoperation calls. As Operations are compiled to ESMs, the complete instruction marks the state completion and replaces the usual return instruction. The major difference however lies in the stack handling, which had to be changed to the StateMachine behavior. The event and trans instructions enable immediate changes in the control flow through an explicit event or transition, respectively. This may cause an immediate exit from the current State implementation. The event command can be regarded as an ESM-compatible replacement for the traditional int/trap instruction.Concurrency is supported through asynchronous operations calls using the invokea instruction. Such a call creates a new thread which is implicitly terminated by the completion of the operation.Furthermore, the UVM supports explicit switching between different threads of execution through the continue operation. it causes the UVM to save to current thread state to its stack, restore the state of the thread specified by the operand and continue execution in that thread. This operation used by the scheduler.Table 1. UVM Instruction Set (excerpt) Mnemonic DstSrc SemanticsData Movement & Stack Instructionsmove.[b,l,d] mem mem/im Dst← Srcpush.[b,l,d] mem [-sp]← Dstpop.[b,l,d] mem Dst← [sp+]enter imm (Initialize local frame)Math Instructionsadd.[b,l,d] mem mem/im Dst← Dst + Srccmp.[b,l,d] mem mem/im [Flags according]...Logical InstructionsNot.[b,l,d] mem Dst← ~DstAnd.[b,l,d] mem mem/im Dst← Dst ∧ Src ...Shift InstructionsAsl.[b,l,d] mem mem/im Dst← Dst << Src Lsl.[b,l,d] mem mem/im Dst←Dst <<< Src...Control InstructionsbCC disp Conditional branchbra disp Unconditionalbranch OO Control Instructionsnew memmem/imDst← (instanceof Src)destroy mem (destroy instance Dst)interface memmem Dst← Dst as Srcinvoke mem Im (invoke Src on Dst)fork mem Im (fork Src on Dst)invokes mem Im (invoke static Src on Dst) invokei mem Im (interface op Src on Dst) ...Synchronization Instructionsjoin mem (join thread Dst)sync mem (obtain instance lock)trysync mem (lock if possible)release mem (release instance lock)ESM Control Instructionstrans mem (transition to Dst)event mem (event Dst will becomplete (return)Thread Control Instructionscontinue Mem (continue Thread Dst) 5.ExampleAs an example, we outline the implementation of the well-known ZMODEM protocol [8] for file transfers, i.e., used in Telnet sessions. We focus on the significant partsof the receiver implementation to demonstrate the basic concepts of our approach.The implementation is presumed to be contained in a class ZModem with operations for sending and receiving files. Figure 2 shows a cutout of the state diagram for the receive() operation. The operation is returning a set of File objects representing the received files. The implementation closely resembles the ZMODEM state machine and thus demonstrates nicely the use of an existing StateMachine design in our approach. The provided tags define the event and action processing in this StateMachine as consuming ZMODEM Frames (data packets) using the frame type as the triggering event. The corresponding action is sending back response ZMODEM FrameHeader objects. This leads to a complete implementation of the StateMachine based on the protocol frame types.The StateMachine starts by sending a ZRINIT headerto initiate the file transfer and waiting for a ZFILE frame header response with as a trailing subpacket containing the name and size of the file to be received. It retries this up to MaxZRININT times before giving up. This illustrates the use of timeouts in our approach.Once a ZFILE frame header has been successfully received, the transition to the CheckFile state takes place. This state is implemented by the SD (Interaction) shownin Figure 3.。

软件设计师-计算机专业英语(四)(总分30, 做题时间90分钟)综合知识试题It should go without saying that the focus of UML is modeling. However, what that means, exactly, can be an open-endedquestion. (1) is a means to capture ideas,relationships,decisions, and requirements in a well-defined notation that can be applied to many different domains. Modeling not only means different things to different people, but also it can use different pieces of UML depending on what you are trying to convey. In general, a UML model is made up of one or more (2) . A diagram graphically represents things, and the relationships between these things. These (3) can be representations of realworldobjects,pure software constructs, or a description of the behavior of some other objects. It is common for an individual thing to show up on multiple diagrams; each diagram represents a particular interest, or view, of the thing being modeled. UML 2.0 divides diagrams into two categories: structural diagrams and behavioraldiagrams. (4) are used to capture the physical organization of the things in your system, i.e., how one object relates toanother. (5) focus on the behavior of elements in a system. For example, you can use behavioral diagrams to capture requirements, operations, and internal state changes for elements.SSS_SINGLE_SEL1.A ProgrammingB AnalyzingC DesigningD ModelingSSS_SINGLE_SEL2.A viewsB diagramsC userviewsD structurepicturesSSS_SINGLE_SEL3.A thingsB picturesC languagesD diagramsSSS_SINGLE_SEL4.A ActivitydiagramsB Use-casediagramsC StructuraldiagramsD BehavioraldiagramsSSS_SINGLE_SEL5.A Activity diagramsB Use-case diagramsC Structural diagramsD BehavioralObject-oriented analysis (OOA) is a semiformal specification technique for the object-oriented paradigm. Object-oriented analysis consists ofthree steps. The first step is (6) . It determines how the various results **puted by the product and presents this information in the form of a (7) and associated scenarios. The second is (8) , which determines the classes and their attributes, then determines the interrelationships and interaction among the classes. The last step is (9) , which determines the actions performed by or to each class or subclass and presents this information in the form of (10) .SSS_SINGLE_SEL6.A use-casemodelingB classmodelingC dynamic modelingD behavioralmodelingSSS_SINGLE_SEL7.A collaborationdiagramB sequencediagramC use-case diagramD activity diagramSSS_SINGLE_SEL8.A use-casemodelingB classmodelingC dynamicmodelingD behavioralmodelingSSS_SINGLE_SEL9.A use-casemodelingB classmodelingC dynamicmodelingD behavioralmodelingSSS_SINGLE_SEL10.A activity diagramB component diagramC sequence diagramD state diagramPeople are indulging in an illusion whenever they find themselves explaining at a cocktail(鸡尾酒 ) party, say, that they are "in computers," or " in **munications," or "in electronic funds transfer". The implication is that they are part of the high-tech world. Just between us, they usually aren't. The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are (11) of their work. We **puters and other new **ponents to develop our products or to organize our affairs. Because we go about this work in teams and projects and other tightly knit working group(紧密联系在一起的工作小组 ), we are mostly in the**munication business. Our successes stem from good humaninteractions by all participants in the effort, and our failures stem from poor human interactions.The main reason we tend to focus on the (12) rather than the human side of work is not because it's more (13) , but because it's easier to do. Getting the new disk drive installed is positively **pared to figurine out why Horace is in a blue funk(恐惧)or why Susan is dissatisfied with **pany aver only a few months. Human interactions **plicated and never very crisp(干脆的,干净利落的) and clean in their effects, but they matter more than any other aspect of the work.If you find yourself concentrating on the (14) rather than the (15) , you're like the vaudeville character(杂耍人物)wholoses his Keys on a dark street and looks for them on the adjacent street because, as he explains, "The light is better there!\SSS_SINGLE_SEL11.A creatorsB innovatorsC appliersD inventorsSSS_SINGLE_SEL12.A technicalB classicalC socialD societalSSS_SINGLE_SEL13.A trivialB crucialC minorD insignificantSSS_SINGLE_SEL14.A technologyB sociologyC physiologyD astronomySSS_SINGLE_SEL15.A technologyB sociologyC physiologyD astronomyObserve that for the programmer, as for the chef, the urgency of the patron(顾客)may govern the **pletion of the task, but it cannot govern the **pletion. An omelette(煎鸡蛋 ), promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—waits or eats it raw. Software customers have had (16) choices.Now I do not think software (17) have less inherent courage and firmness than chefs, nor than other engineering managers. But false (18) to match the patron's desired date is much **mon in our discipline than elsewhere in engineering. It is very (19) to make a vigorous, plausible, and job risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating roles, and so on. The whole profession can only profitfrom (20) such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish derived estimates.SSS_SINGLE_SEL16.A noB the sameC otherD lots ofSSS_SINGLE_SEL17.A TestersB constructorsC managersD architectsSSS_SINGLE_SEL18.A TasksB jobsC WorksD schedulingSSS_SINGLE_SEL19.A easyB difficultC simpleD painlessSSS_SINGLE_SELA sharingB excludingC omittingD ignoringWhy is (21) fun? What delights may its practitioner expect as his reward? First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. Second is the pleasure of making things that are useful to other people. Third is the fascination of **plex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences ofprinciples built in from the beginning. Fourth is the joy of always learning, which springs from the(22) nature of the task. In one way or another the problem is ever new, and its solver learns something:sometimes (23) , sometimes theoretical, and sometimes both. Finally, there is the delight of working in such a tractable medium. The (24) , like the poet, works only slightly removed from pure thought-stuff. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.Yet the program (25) , unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.SSS_SINGLE_SEL21.A programmingB composingC workingD writingSSS_SINGLE_SEL22.A repeatingB basicC non-repeatingD advanceSSS_SINGLE_SELA semanticB practicalC lexicalD syntacticalSSS_SINGLE_SEL24.A poetB architectC doctorD programmerSSS_SINGLE_SEL25.A constructB codeC sizeD scaleFor nearly ten years, the Unified Modeling Language (UML) has been the industry standard for visualizing, specifying, constructing, and documenting the (26) of a software-intensive system. Asthe (27) standard modeling language, the UML **munication and reduces confusion among project (28) The recent standardization of UML 2.0 has further extended the language's scope andviability.Its inherent expressiveness allows users to(29) everything from enterprise information systems and distributed Web-based applications to real-time embedded systems. The UML is not limited to modeling software. In fact, it is expressive enough to model (30) systems, such as workflow in the legal system, the structure and behavior of a patient healthcare system, software engineering in **bat systems, and the design of hardware. To understand the UML, you need to form a conceptual model of the language, and this requires learning three major elements: the UML's basic building blocks, the rules that dictate how those building blocks may be put together, and **mon mechanisms that apply throughout the UML.SSS_SINGLE_SEL26.A classesB componentsC sequencesD artifactsSSS_SINGLE_SEL 27.A realB legalC de factoD illegalSSS_SINGLE_SEL 28.A investorsB developersC designersD stakeholdersSSS_SINGLE_SEL 29.A modelB codeC testD modifySSS_SINGLE_SEL 30.A non-hardwareB non-softwareC hardwareD software1。

计算机（信息技术）教师编制考试试题及答案1.面向对象程序设计以__(1)__为基本的逻辑构件，用__(2)__来描述具有共同特性的一组对象；以__(3)__为共享机制，共享类中的方法和数据。

(1)A．模块B．对象C．结构D．类(2)A．类型B．抽象C．类D．数组(3)A．引用B．数据成员C．成员函数D．继承2.链表不具有的特点是__(4)__。

(4)A．可随机访问任何一个元素 B．插入、删除操作不需要移动元素C．无需事先估计存储空间大小 D．所需存储空间与线性表长度成正比3.对矩阵压缩存储的重要目的是__(5)__。

(5)A．方便运算B．节省存储空间C．减少计算复杂度D．提高运算速度4.判断“链式队列为空”的条件是__(6)__（front为头指针，rear为尾指针）。

(6)A．front==NULL B．rear==NULLC．front==rear D．front!=rear5.以下关于字符串的鉴定语句中对的的是__(7)__。

(7)A．字符串是一种特殊的线性表 B．串的长度必须大于零C．字符串不属于线性表的一种 D．空格字符组成的串就是空串6.在具有100个结点的树中，其边的数目为__(8)__。

7.程序设计语言的定义一般应包 __(9)__几个方面。

(9)A．语法、语义和语句 B．语法、语义和语用C．语义、语句和语用 D．语法、语用和语句8.在C语言中，若函数调用时实参是数组名，则传递给相应形参的是__(10)__。

(10)A．数组空间的首地址B．数组的第一个元素值C．数组中元素的个数D．数组中所有的元素9.在下面的程序中，若实参a与形参x以引用调用(call by reference)的方式传递信息，则输出结果为__(11)__；若实参a与形参x以值调用(callbyvalue)的方式传递信息，那么输出结果为__(12)__。

Mainprograma:=1；addone(a)；write(a)；Procedure addom(x)a:=x+1；x:=x+2；return；(12)A．1 B．2 C．3 D．410.在程序的执行过程中，用__(13)__结构可实现嵌套调用函数的对的返回。

I&V Senior SpecialistAdditional Requirements:- Telecommunication industry background is a must- Fluent written and spoken English is required- Testing experience is required- System testing background is preferred much- WCDMA/GSM/LTE/WiMax background is preferred- Familiar with testing process and SW development processes- TCPIP or Linux experience is a plus- Experience on call processing or call mobility is a plus- Experience on WCDMA testing is a plus- Test automation tool usage/development experience is a pluspersonal attributes- Open to innovation, active, self driven and flexible- Eager to learn new technology and willing to accept challenge.- Be team player- Willing to work in a multi-cultural environmentBB HW Automation Test SpecialistJob description:- Hardware automated/integration test of both digital baseband boards and base station products.- Design and maintain automated tests and test tools.- Write product test plans, test specifications and procedures.- Define test cases for hardware functionality, performance, regression and reliability test.- Test case implementing and coding.- Execute test and create test report.- Work closely with development engineers and other teams like SW, RF, PSU and ME to analyze and find root cause of failures/bugs.Requirement:- MSc/BSc degree in Electrical Engineering or related.- 3/5+ years experience in digital hardware design or hardware test, or hardware related software development like driver or embedded software in network/communication products.- Skilled in Python scripting language, or other programming language like Tcl/Tk, Perl or C/C++. - Experience in handling logic analyzer, high speed oscilloscope, signal generator, spectrum analyzers and microprocessor debugger.- Linux and network programming knowledge, TCP/IP, socket, telnet and so on is a plus.- Knowledge of 3GPP, CPRI, OBSAI standards is a plus.- RF knowledge is a plus.- Fluent written and spoken English.Personal Attributes:- Good communication and problem solving skills.- You are a team player.BB HW Board DesignerJob description:- System module products hardware baseband circuitry design and verification.Requirement:- MSc/BSc degree in Electrical Engineering or related.- 3+ years experience in digital hardware development.- Experience in handling high speed oscilloscope, logic analyzer, signal generator and microprocessor debugger.- Knowledge and actual project experience in high-speed SerDes circuitry design, debug and verification.- Knowledge and actual project experience in high-speed signals PCB routing rule.- Knowledge of interfaces and protocols in the telecommunication technology (CPRI, OBSAI or ITU -T standard interfaces) is a plus- High-speed pre-simulation and post-simulation skill is a plus- Fluent written and spoken English.Personal Attributes:- Good communication and problem solving skills.- You are a team player.System Testing SpecialistMain Responsibility Area:·Requirement analysis,·Testing environment setting up,·Creating test case set,·Executing test case set,·Analyze test results,·Fault reporting,·Cooperation with SW developers in different countries,Position Description:·M.Sc. or B.Sc. degree in Telecommunication Engineering, Computer Science or equivalent. ·Experience in embedded software, Esp. in telecommunication equipment.·Basic knowledge on 3GPP standard, algorithms design and implementation.·Good knowledge in TCP/IP·Knowledge of Mobile MGW product will be seen as an advantage·Some knowledge about software testing tools and test automation systems·Knowledge of SW development and testing processes·MSS product knowledge is an advantage·Fluent in written and spoken English and MandarinPosition Requirements:·Proven to be quick learner and good team player, take responsibilities and initiatives·Self-motivated, target driven and innovative thinking·Open minded and willing to accept challengeSW Engineer - CI SpecialistJob description:SCM CI Specialist is responsible for design, implementation and maintenance of automated SW builds and environment for multiple platforms. SCM CI Specialist will support and continue to optimize the build process, research and recommend new build and deployment technologies. SCM CI Specialist communicates daily with development team members supporting several phases of development life cycle including deployment requirements, testing and rebuilds, and release into production environments. Works with Architecture team to enforce, refine, and streamline software build and deployment process.Requirement:- Strong experience in Software Configuration Management area and Continuous Integration- Strong experience in Python/Perl/Shell scripting- Knowledge of software development processes and tools- MSc or BSc in Computer Science, Telecommunications or equivalent- Fluent written and spoken English- Personal Attributes:- Good interpersonal and teamwork skills- Ability to communicate and co-operate with other people in various situations- Strong analytical skills are an important advantageSW Engineer - Python SpecialistJob description:SCM Python Specialist is responsible for design, implementation and maintenance of automated SW builds and environment for multiple platforms. SCM Python Specialist will support and continue to optimize the build process, research and recommend new build and deploymenttechnologies. SCM Python Specialist communicates daily with development team members supporting several phases of development life cycle including deployment requirements, testing and rebuilds, and release into production environments. Works with Architecture team to enforce, refine, and streamline software build and deployment process.Requirement:- Experience in Software Configuration Management area and Continuous Integration- Strong experience in Python/Perl/Shell scripting- Knowledge of software development processes and tools- MSc or BSc in Computer Science, Telecommunications or equivalent- Fluent written and spoken EnglishPersonal Attributes:- Good interpersonal and teamwork skills- Ability to communicate and co-operate with other people in various situations- Strong analytical skills are an important advantageJava SW Engineer / Senior Java SW EngineerJob description:- Java SW developers are for Nokia Siemens Networks WCDMA BTS (3G) & LTE SW development and research. Be responsible for SW design, implementation and testing of BTS Site Manager software, which is a Java based UI application running on PC. It manages the WCDMA & LTE BTS (base station) and Transport equipment.Requirement:Mandatory skills:- -Fluent spoken and written English skills- -Good communication skills- -Java SW design, implementation and testing skills- -Experience of object oriented software using UML and Java- -Master or Bachelor degree in SW engineering, computer science or telecomAdvantage:- -UI design skills- -WCDMA / mobile networks / telecommunication knowledge- -Design patterns- -Swing experienceIOT System EngineerMain Purpose of the Role and Key ResponsibilitiesOverall responsibility of specified entities ( e.g. features). Plans, designs and executes items in own area. Coordinates activities within own responsibility area. Has developed specialist knowledge in one area. Coaches other team members in solving basic engineering problems. Solves complex engineering problems of own technology area. Typically participates in reviews of own or neighbouring projects. May undertake technical training responsibilities.- Perform Terminal IOT and e2e functional testing between NSN TD-LTE NW implementation and new and existing Terminals- Perform Terminal IODT and functional testing mainly between NSN TD-LTE systems and some pre-selected terminal or chipset vendors- Perform Software and hardware upgrade as well as configuration of the NSN TD-LTE elements to meet IOT requirements- Perform analysis, design and review test plan and test case with vendors and customers, write test specifications, perform testing and troubleshooting, and reporting.Requirements- Many years of experience in working with telecommunication open standards (3GPP, IETF, ETSI). - Multiple years of experience in testing of UMTS and IP networks and analytical problem solving skills are needed. Experience in LTE/TD-LTE is a plus.- Multiple years of experience in test case development and test planning.- Multiple years of hands-on experience in UMTS/LTE network elements.- Very strong experience testing radio network system testing, analyzing protocols stacks using protocol analyzer tools.- Very strong understanding of radio interfaces and other key critical interfaces, protocols, and architecture of 3GPP network.- Strong working knowledge of and experience with IP networking protocols such as IPv4 and IPv6 and Internet technologies (TCP/IP, DNS, HTTP, Radius, Diameter) is a plus.- Experience in any of the following skills will be an additional asset: Mobile IP, GTP and other network mobility protocols.- Multiple years of technical experiences in the area of e2e system verification is a plus.- Many years of experience configuring and integrating GSM/GPRS/EDGE/UMTS/LTE and IP networks products in multivendor environment is a plus- Light, occasional travel may be required.- Fluent in EnglishPersonal Attributes- Self motivated well-organized individual who can prioritize work and handle multiple tasks.- Goal-oriented decision making and quick grasp of new matters- Excellent team player with positive mindset, open minded and willingness to learn- Solid technical background including ability to interact effectively with variety of organizations and works well with people under high pressure in fast paced environment- Creative and analytical thinking, very imaginative to do systematic testing to find faults before customer does- Able to work and understand complex issues and work systematically- Terminal and Network testing and troubleshooting skillsWCDMA软件/测试工程师主要职责:- 负责指定领域软件的设计、实现、测试及其维护。

Target platforms needed to be the first choice when developing sys-tems using assembler.Moving on to C, designers had more flexibility. But they were quickly locked into a specific target as the run-time libraries prevented migra-tion to different platforms. This progression leads to model-based design (see the figure).Targets, Targets, TargetsPlatform choice was less of an issue when there were fewer targets available. Yet these days, the options are mindboggling. It’s no longer just a choice between processor A and processor B. Digital signal processors (DSPs), digital signal controllers (DSCs), multiple core processors,and even FPGAs are viable targets for embedded systems.With real estate, it’s location,location, location. With embedded solutions, it’s target, target, target.Optimizing system cost, perform-ance, and flexibility means choosing the proper target. But these days,software is such an important part of the solution, the choice of target and software tools is tied together—that is, unless you use abstraction to disconnect these choices.Programmers continue to move to higher levels of abstraction. Most production programming langauages now incorporate software platforms.These platforms provide a standardoperating environment that isolates the application from the hardware.Eventually, though, the application must touch the bounds of peripher-als. Likewise, conventional pro-gramming languages and design methodologies typically assume a conventional processor architecture that even covers DSPs and DSCs,but not FPGAs.Abstraction, Abstraction,AbstractionModel-based design also shares the boundary problem that high-level environments have. But because the object models tend to abstract this interface, programmers can be even more isolated from the target.Abstraction environments such as the Object Management Group’s (OMG’s)Unified Modeling Language (UML) and National Instruments’LabView offer even more advantages because the target selection can bea processor, an FPGA, or even an FPGA with an embedded hard-core or soft-core processor.The modeling environment trans-lates objects into programming code or FPGA design code when the tar-get environment is created. Object customization occurs at a higher,specification-level instead of lower-level code.This level of abstraction is even more important as the model-based design envelops a system design that includes multiple processors and FPGAs. In this case, objects within a design are spread across a collection of targets. This approach lets design-ers choose object distribution so an object’s target can change based on design requirements. Do you need more speed? Try moving that part of the application into an FPGA. It will be much easier with model-based design abstraction than trying to translate C code into VHDL.Choose Targets After AbstractionA Supplement to Electronic Design/March 16, 2006Sponsored by National InstrumentsModel-Based DesignWilliam WongEmbedded /Systems /Software EditorAssemblerCC++C#, JavaModel designSystem complexityA b s t r a c t i o nED ONLINE 12086Programmers have had to move to improve. C remains the mainstay for embedded development, but programmers are migrating to higher levels of abstraction as project size and complexity grows.Specific target:Analog Devices Blackfin Type:Digital signal controllerDescription: The Blackfin 16-bit fixed-point processor mixes aspects of DSP and conven-tional design, enabling it to address a wide range of applications, including motor-control applications.Advantages:Its high-performance architecture employs a number of parallel execution units,such as address generation and multiply accu-mulates (MACs).Disadvantages:It lacks the floating-point capa-bility found in higher-end DSPs. It also may be overkill for some applications.A Model-Based Graphical Approach Can Target Multiple POverview: Model-based design can readily express data-flow designs such as closed loop feedback motor-control applications. The graphical model design does not indicate what type of target platform will be utilized. But it is possible to choose any one of a number of platforms, as noted in the examples below. Model-based design tools can readily express a wide range of embedded applications.Target type:Processor Options:MPU, DSP, DSC Generated :Program source code; typically C source code Issues:Does the processor have enough compute power to perform the desired func-tions within the required time frame?Advantages:Normally lower cost compared to custom or FPGA solutions; wide range of performance options; han-dles sequential tasks well Disadvantages:Single thread of executionAnalog Devices BlackfinIndex Index Index Index Limit Base Modify Limit Base Modify Limit Base Modify Limit Base ModifyData address generator Data address generator16-bit MAC 16-bit MAC 8-bit video 8-bit video8-bit video8-bit videoBarrel shifter40-bit ALU 40-bit ALU AccumulatorAccumulatorControl unit SequencerAlign Decode Loop bufferSP FP P5P4P3P2P1P0R7R6R5R4R3R2R1R0Target processorConfiguring a filter: Model-based design uses object customization that can be sim-ple or complex, as in this digital filter exam-ple. The design interface may allow a range of choices, such as whether computations are done using integers, fixed-point, or float-Amplifier Controller+–latformsTarget type:FPGAOptions:Embedded CPU coreGenerated:FPGA content, layout,and configuration filesIssues:Does the FPGA haveenough gates for the desired func-tions? Does the FPGA haveenough performance to executethe algorithm?Advantages:Parallel processing;can mix custom logic with soft-ware running on hard or soft coresDisadvantages:Chips tend to bemore expensive than conventionalmicrocontrollers, DSCs, or DSPs;difficult to program without graph-ical design toolsSpecific target:Xilinx Vertex-4 FXType:FPGA with hard coreProcessor:32-bit PowerPC405 core Description: The Vertex-4 FX incorporates one PowerPC or more along with numerous logic blocks. Each block’s four slices contain four-input lookup tables (LUT), flip-flops, multiplexers, arithmetic logic, carry logic, and dedicated internal routing. Advantages:Its auxiliary processor unit (APU) controller simplifies integration of hardware coprocessors.Disadvantages:Designers may have to deal more closely with design, layout, and routing on complex designs.Logic cellRocket IOMultiplexersLogicLatchesControlLogic cellRAMClockmanagerDifferentialIOEthernetMAC450-MHzPowerPCcorePhasedclockdividersXtremeDSPsliceConfigurationmemorySwitch cellGraphical Model-Based DesignPros: Designers can concentrate on solving theproblem rather than figuring out whether it fitswithin the constraints of a particular hardware. It’seasier to incorporate other objects into a designcompared to utilizing run-time libraries in a soft-ware implementation approach.Cons: Model-based design is a new approach formany developers, especially those using text-based development tools.Xilinx FPGA Target FPGAing-point values, or what the filter’s frequen-cy response might be. Graphical presenta-tions such as the one above give designers immediate feedback about a range of inputs. At this point, the design does not indicate which target platform will be used.MotorPlant AmplifierA Supplement to Electronic Design/March 16, 2006。

uml书的参考文献参考文献:1. Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The unified modeling language user guide. Pearson Education.2. Fowler, M., Scott, K., & UML Distilled. (2004). A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional.3. Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Pearson Education.4. Ambler, S. W. (2002). The Object Primer: Agile Model-Driven Development with UML 2.0. Cambridge University Press.5. Arlow, J., & Neustadt, I. (2005). UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design. Addison-Wesley Professional.6. Stevens, P., Pooley, R., & Brook, P. (2000). Using UML: Software Engineering with Objects and Components. Addison-Wesley Professional.7. Alhir, S. S. (2004). Advanced Database Projects in Access 2007: Suitable for Users of Office 2010. Prentice Hall.8. Gomaa, H. (2011). Software Modeling and Design: UML, UseCases, Patterns, and Software Architectures. Cambridge University Press.9. Schmuller, J. (2004). Sams Teach Yourself UML in 24 Hours. Sams Publishing.10. Jacobson, I., Christerson, M., Jonsson, P., & Overgaard,G. (2004). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Professional.参考文献中提到的书籍涵盖了UML的各个方面，从初学者向导到进阶实践都有所涉及。

ISSN 1000-9825, CODEN RUXUEW E-mail: jos@Journal of Software, Vol.21, No.5, May 2010, pp.899−915 doi: 10.3724/SP.J.1001.2010.03700 Tel/Fax: +86-10-62562563© by Institute of Software, the Chinese Academy of Sciences. All rights reserved.∗复杂嵌入式实时系统体系结构设计与分析语言:AADL杨志斌1+, 皮磊2, 胡凯1, 顾宗华3, 马殿富11(北京航空航天大学计算机学院,北京 100191)2(Toulouse Institute of Computer Science Research, Toulouse, France)3(浙江大学计算机科学与技术学院,浙江杭州 310027)AADL: An Architecture Design and Analysis Language for Complex Embedded Real-TimeSystemsYANG Zhi-Bin1+, PI Lei2, HU Kai1, GU Zong-Hua3, MA Dian-Fu11(School of Computer Science and Engineering, BeiHang University, Beijing 100191, China)2(Toulouse Institute of Computer Science Research, Toulouse, France)3(College of Computer Science and Technology, Zhejiang University, Hangzhou 310027, China)+ Corresponding author: E-mail: kenney@Yang ZB, Pi L, Hu K, Gu ZH, Ma DF. AADL: An architecture design and analysis language for complexembedded real-time systems. Journal of Software, 2010,21(5):899−915. /1000-9825/3700.htmAbstract: This paper firstly presents a summary of AADL (architecture analysis and design language), includingits progress over the years and its modeling elements. Then, it surveys the research and practice of AADL from amodel-based perspective, such as AADL modeling, AADL formal semantics, model transformation, verification andcode generation. Finally, the potential research directions are discussed.Key words: complex embedded real-time system; system architecture; model driven; AADL (architecture analysis anddesign language)摘要: 首先归纳了AADL(architecture analysis and design language)的发展历程及其主要建模元素.其次,从模型驱动设计与实现的角度综述了AADL在不同阶段的研究与应用,总结了研究热点,分析了现有研究的不足,并对AADL的建模与分析工具、应用实践进行了概述.最后,探讨了AADL的发展与研究方向.关键词: 复杂嵌入式实时系统;系统体系结构;模型驱动;AADL(architecture analysis and design language)中图法分类号: TP311文献标识码: A复杂嵌入式实时系统广泛应用于航空电子、航天器、汽车控制等领域,这些系统具有资源受限、实时响应、∗Supported by the National High-Tech Research and Development Plan of China under Grant Nos.2007AA01A127, 2006AA01Z19A(国家高技术研究发展计划(863)); the Aviation Science Foundation of China under Grant Nos.20081951027, 2007ZC51032,20060151003 (航空科学基金); the RGC CERG of Hong Kong of China under Grant No.613506 (香港研究资助局面上项目); theTOPCASED Project in France (法国TOPCASED项目)Received 2009-01-08; Revised 2009-04-27; Accepted 2009-07-09900 Journal of Software软件学报 V ol.21, No.5, May 2010容错、专用硬件等特点,对实时性、可靠性等性质有较高的要求,文献[1]称其为性能关键系统(performance critical systems,简称PCS).由于计算精度、实时响应的要求,这类系统变得越来越复杂,如何设计与实现高质量的复杂嵌入式实时系统,并有效控制开发时间与成本,是学术界和工业界共同面临的难题.模型驱动开发方法(model driven development,简称MDD)能够在早期阶段对系统进行分析与验证,有助于保证系统的质量属性,并有效控制开发时间与成本.而质量属性是由系统体系结构决定的[1].因此,基于体系结构模型驱动(model-based architecture-driven)的设计与开发方法成为复杂嵌入式系统领域的重要研究内容.其中一个重要的方面就是研究合适的体系结构描述语言.常用的体系结构描述语言主要有UML(unified modeling language)和ADL(architecture description language).UML侧重描述系统的软件体系结构,为了支持嵌入式实时系统的非功能属性分析,OMG(Object Management Group)先后定义了UML Profile for SPT(schedulability, performance, and time,简称SPT)[2],UML Profile for Qos/FT(quality of service and fault tolerance,简称Qos/FT)[3]以及UML Profile MARTE(modeling and analysis of real-time and embedded systems)[4],它们继承了UML的多模型多分析方法,因此模型之间可能存在不一致性;而C2,Darwin,Wright,Aesop,Unicon,Rapide等ADL都是通用领域的软件体系结构描述语言,难以满足软硬件协同设计、实时响应、资源受限等特定需求;MetaH是面向航空电子系统的ADL,可以用于嵌入式实时系统体系结构描述与分析,但MetaH在支持运行时体系结构描述、可扩展、与其他ADL兼容以及复杂系统设计等方面有所欠缺.2004年,美国汽车工程师协会SAE(society of automotive engineers)在MetaH,UML的基础上,提出嵌入式实时系统体系结构分析与设计语言AADL(architecture analysis & design language)[5],并发布为SAE AS5506标准,目的是提供一种标准而又足够精确的方式,设计与分析嵌入式实时系统的软、硬件体系结构及功能与非功能性质,采用单一模型支持多种分析的方式,将系统设计、分析、验证、自动代码生成等关键环节融合于统一框架之下.AADL具有语法简单、功能强大、可扩展的优点.由于具有广阔的应用前景,AADL得到了欧美工业界,特别是航空航天领域(如Airbus,Lockheed Martin,Rockwell Collins,Honeywell,Boeing)的支持;CMU(Carnegie Mellon University),MIT(Massachusetts Institute of Technology),UIUC(University of Illinois at Urbana- Champaign),Pennsylvania大学,NASA以及法国IRIT(Toulouse Institute of Computer Science Research),INRIA, Verimag等研究机构对AADL展开了深入研究与扩展.TOPCASED[6],SPICES[7],AVSI-SAVI[8]等是欧美工业界和学术界共同参与的AADL重大研究项目,涉及AADL标准扩展、建模工具、形式语义、验证、可靠性分析、可调度分析以及自动代码生成等方面的研究,这些也是目前AADL的研究热点.AADL被认为是基于模型驱动的嵌入式实时系统设计与实现的基础,但AADL还有很多问题需要进一步研究与完善.本文试图从模型驱动设计与开发的角度,综述近几年AADL的研究成果,剖析一些重要概念,如执行模型(execution model),总结研究热点以及分析现有研究的不足.第1节简介AADL的发展历程及其建模元素.第2节分述AADL语言的研究、基于AADL的建模方法、AADL模型的验证与分析以及基于AADL模型的自动代码生成等内容.第3节介绍AADL现有的建模与分析工具.第4节概述AADL的应用实践.最后讨论AADL可能的研究发展方向.1 AADL简介1.1 AADL发展历程AADL创始人Peter H. Feiler和Bruce A. Lewis总结了AADL的发展历程[1],提出AADL是在MetaH,ADL 以及商业建模语言UML和HOOD(hierarchical object-oriented design)[9]的基础上发展起来的.1991年,在美国DARPA计划DSSA(domain specific software architectures)项目支持下,Honeywell 实验室提出体系结构描述语言MetaH,专用于航空电子、飞行控制等系统的体系结构描述与分析.到1999年,学术界和工业界对MetaH进行了大量研究与应用,如支持多处理器系统建模、Ada95和POSIX中间件配置、MetaH-ACME的转换、可靠性建模等.2001年,SAE提出基于MetaH定义一个航空电子体系结构描述语言标准,即Avionics Architecture杨志斌 等:复杂嵌入式实时系统体系结构设计与分析语言:AADL 901 Description Language(AADL),支持描述标准的航空电子控制与数据流机制及实时、容错、安全等非功能性质.2004年,AADL 标准化得到了进一步的扩展.SAE,CMU,Honeywell 等共同提出建立嵌入式实时系统体系结构描述语言标准,并正式命名为Architecture Analysis & Design Language(AADL).2004年11月,发布了AADL1.0版本,以文本的形式给出核心语言的语法和语义.2006年发布了一些扩展附件(annex),如Graphical AADL Notation Annex [10],AADL Meta model and XML/XMI Interchange Format Annex [10],Error Model Annex [10], Behavior Annex [11],UML Profile Annex.2009年1月发布了AADL 2.0版本[12].1.2 AADL 建模元素AADL 通过构件、连接等概念描述系统的软、硬件体系结构;通过特征、属性描述系统功能与非功能性质;通过模式变换(mode change)描述运行时体系结构演化;通过用户定义属性和附件支持可扩展;对于复杂系统建模,AADL 通过包(package)进行组织.AADL 提供了3种建模方式:文本、XML 以及图形化.如图1所示,本文以汽车巡航控制系统(cruise control system)的AADL 模型为例,介绍AADL 的基本建模元素.Speed DisplayCommandSpeedVoltage ThrottleVoltageRequired speedActual speed Tours per periodSpeed SpeedVoltage Tour Event port connection Data port connection CruiseProcess20Hz 50Hz 100Hz 20Hz SpeedBus WheelProcess MemoryProcessor Tours per period Tour CruiseSystemWheelFig.1 Graphic AADL model of an automotive cruise-control system图1 汽车巡航控制系统的AADL 图形化模型(1) 构件种类AADL 定义了3类构件:软件构件、执行平台构件以及系统构件.软件构件用于软件体系结构建模,包括数据(data)、线程(thread)、线程组(thread group)、进程(process)、子程序(subprogram)构件;执行平台构件用于硬件体系结构建模,包括处理器(processor)、虚拟处理器(virtual processor)、存储器(memory)、总线(bus)、虚拟总线(virtual bus)、外设(device)构件;系统构件组合所有的构件,层次化地建立系统的体系结构.在图1中,采用系统构件(CruiseSystem)、进程构件(WheelProcess,CruiseProcess)、线程构件(Wheel,Throttle,Speed,Command, Display)、处理器构件、存储器构件以及总线构件构造系统的体系结构模型.902 Journal of Software软件学报 V ol.21, No.5, May 2010(2) 构件描述AADL构件被定义为两部分:类型(component type)和实现(component implementation).一个构件拥有一个类型以及对应的0个、1个或多个实现.构件类型描述对外的功能接口(输入输出端口等).构件实现则描述构件的内部结构(子构件、连接等),例如,进程构件CruiseProcess由4个线程子构件及其连接来实现.构件类型和实现都是可继承的.(3) 构件特征特征(feature)是构件类型定义的一部分,用于描述构件的对外接口,主要包括4类:端口、子程序、参数以及子构件访问.端口用于定义构件之间的数据、事件交互接口,分为数据、事件、数据事件端口,图1中主要采用了数据和事件端口进行交互.子程序用于定义子程序共享访问接口,分为子程序访问者(required subprogram access)和子程序提供者(provides subprogram access),前者表示需要访问其他构件内部的子程序,后者表示提供子程序给其他构件来访问,可以支持远程子程序调用.参数用于定义子程序被访问时输入、输出的合法数据类型.子构件访问分为数据构件访问和总线构件访问,前者用于共享数据或共享资源描述,后者用于硬件平台构件之间的连接.(4) 连接、流AADL采用连接(connection)来描述构件之间的交互行为,与构件特征对应,AADL支持3种连接方式:端口连接、参数连接及访问连接.端口连接用于描述并发执行构件之间的数据与控制交互;参数连接描述一个线程构件访问的所有子程序的参数所形成的数据流;访问连接又分为数据访问连接、总线访问连接以及子程序访问连接,分别描述数据共享、总线共享以及子程序共享.连接是点对点的,为了简化对体系结构的分析过程,AADL引入了流(flow)的概念,用于描述系统中信息传输的逻辑路径.流的完整描述包括流规约(flow specification)和流实现(flow implementation).流规约在构件类型中定义,包含外部可见的源结点(flow source)、目标结点(flow sink)及路径(flow path),源结点和目标结点分别是构件的特征,路径则是构件中从一个特征到另一个特征的连接.流实现在构件实现中定义,包括构件中流路径的具体实现或整个系统的端到端流(end-to-end flow)定义.端到端流的描述可以用于支持端到端延迟分析和可靠性分析.(5) 构件属性属性(property)用于描述体系结构中的约束条件,即非功能属性约束,进而支持验证与分析系统的可靠性、安全性、可调度性等性质,如子程序的执行时间、线程的周期、数据或事件端口的等待队列协议、安全层次等.AADL提供了标准的属性集,用户也可以根据需要定义新的属性.属性和特征的区别在于,特征主要是描述构件功能接口,而属性则是描述系统非功能性质的约束.(6) 模式AADL通过模式(mode)来描述运行时体系结构的动态演化.模式就是系统或构件的操作状态,如汽车巡航控制系统可能包括初始化、人工控制、自动巡航等模式.它们对应了系统功能行为的不同配置,模式变换体现系统体系结构的变化,能够描述体系结构重构及容错等需求.(7) 扩展附件当定义新的属性不能满足用户需要时,AADL引入了附件的概念.它拥有独立的语法和语义,但必须与AADL核心标准保持语义一致.如故障模型附件(error model annex)[10],支持构件、连接的故障事件、故障概率等属性建模;行为附件(behavior annex)[11]增强了AADL对构件实际功能行为的详细描述能力,以更好地支持功能行为验证和自动代码生成.另外,时间正确性是实时系统重要的特征,不仅与AADL属性中定义的时间约束(时限、最坏执行时间等)有关,而且与调度算法、调度属性有关.AADL支持描述周期、非周期、偶发等任务模型,支持抢占与非抢占式调度策略,支持多种固定优先级、动态优先级调度算法,如RM(rate monotonic),DM(deadline monotonic), EDF(earliest deadline first)等.这些调度算法定义在处理器构件的属性中.杨志斌等:复杂嵌入式实时系统体系结构设计与分析语言:AADL 903 2 AADL的研究现状2.1 AADL语言的研究为了适应不同的应用需求,AADL语言本身还需要进一步完善和扩展.AADL语言扩展及其语义的形式化目的是为了更好地支持系统体系结构建模与分析.2.1.1 AADL语言扩展AADL提供两种扩展方式:引入新属性或符号以及子语言(sub language)扩展.前者与具体应用相关,允许用户和工具提供商为各种构件引入新的属性集,或专用于特殊分析的符号,如可调度分析工具Cheddar[13],通过定义新的属性集扩展AADL对更复杂调度算法的支持;后者则更严格,需要提议、发展以及被核准,才能成为AADL语言的一部分,一般以AADL附件的形式给出,需要提供子语言的语法和语义.已经被核准的附件有[10]: Graphical AADL Notation Annex,AADL Meta-Model and Interchange Formats Annex,Language Compliance and Application Program Interface Annex,Error Model Annex以及UML Profile Annex.正在发展中的附件有:Behavior Annex[11],ARINC653 Annex.下面对AADL扩展附件进行概述.AADL核心标准是文本形式的,Graphical AADL Notation Annex为AADL定义了一系列图形符号,构件、端口通信、数据共享访问、子程序调用、模式变换、端到端的数据流、属性、附件等元素都能用图形符号表示.但Behavior Annex还没有图形化.目前,AADL的主要建模工具OSATE/TOPCASED[14],STOOD[15]都支持图形化建模,而且能够方便地与文本表示相互转换.Meta Model and Interchange Formats Annex定义了AADL元模型以及基于XML的模型交互格式.元模型定义了AADL语言的结构,也就是AADL模型的对象表示.这些对象表示采用XML标准的交互格式保存,以支持不同工具之间的互操作性.自动代码生成是模型驱动开发的关键环节之一.Language Compliance and Application Program Interface Annex为用户提供了AADL到Ada,C语言代码的转换规则.主要涉及线程、进程、数据等软件构件以及端口通信和子程序调用.Error Model Annex定义了构件和连接建立故障模型的声明规则及语义.故障模型也由两部分组成:类型(error model type)和实现(error model implementation).故障类型可以声明故障状态、故障事件以及故障传播等;故障实现则定义故障状态的变迁,即构件在故障事件发生和故障传播过程中,故障状态是如何变化的.故障状态变迁本质上是一个随机自动机,附件提供Occurrence属性定义故障的发生概率.Error Model Annex可以与多种分析方法结合,如MA(Markov analysis)、DD(dependency diagrams)、ETA(event tree analysis)、FTA(fault tree analysis)、随机Petri网等,从而对系统的可靠性、完整性、可用性以及可维护性进行定量分析.系统行为描述与验证是非常重要的.文献[16]提出,系统行为不仅依赖于AADL构件和连接所描述的静态体系结构,而且依赖于运行时环境.因此AADL提供了执行模型[16,17]的概念来描述运行时环境,用于管理和支持构件的执行,分为同步和异步两种,包括构件分发(dispatch)、同步/异步通信、调度、模式变换等行为.AADL核心标准的默认模式为带同步通信的抢占式调度,在这种模式下,执行模型和系统体系结构的结合能够保证系统行为的可预见性(predictability).线程、子程序构件是最小的执行和调度单元,AADL标准仅描述两者的对外功能接口,而构件内部具体执行行为无法描述.这样就导致在异步执行模型情况下,系统行为的可预见性难以保证.为了更好地分析异步模式下的系统行为,法国IRIT提出了Behavior Annex,对线程和子程序构件的具体行为进行详细描述.Behavior Annex通过状态、变迁来描述构件行为,变迁可以定义触发条件及变迁后的动作,条件和动作主要包括接收/发送数据、子程序调用、异步访问、执行时间、延迟时间等,且通过层次、并发状态来支持更复杂的行为描述.目前,AADL建模工具都支持Behavior Annex的描述.我们认为Behavior Annex与执行模型有密切的关系[18].执行模型的分发机制定义了线程、子程序周期性或非周期性地读取数据、计算、发送数据,Behavior Annex则是对计算状态内的执行行为进行详细刻画.也就是说,904 Journal of Software软件学报 V ol.21, No.5, May 2010执行模型定义了Behavior Annex何时执行、哪些数据被执行,而Behavior Annex处于构件内部,对线程、子程序构件的执行进行更精确的描述.因此,静态体系结构、执行模型及Behavior Annex组成一个完整的AADL模型.以线程构件为例,图2给出了三者的关系.Execution modelFig.2 Structure, execution model and behavior annex图2 体系结构、执行模型及行为附件的关系随着AADL在工业界的广泛应用,对AADL扩展的需求会更多.在航空航天领域,ARINC653是重要的航空电子应用软件接口标准,文献[19,20]研究了AADL与ARINC653标准之间的结合.在自动控制领域,AADL可以与该领域的OSEK[21],AutoSAR[22],EAST-ADL[23]等标准结合.2.1.2 AADL形式语义形式化方法能够对语义进行更精确的刻画,有助于体系结构验证与分析.体系结构、执行模型和行为描述构成一个完整的AADL模型,因此AADL语义也涉及这3个方面.AADL采用混成自动机(hybrid automata)对线程、进程、处理器、虚拟处理器构件的执行状态和动作进行了语义描述,但对通信、模式变换、同步/异步访问等执行模型语义以及Behavior Annex语义没有形式化,主要采用自然语言和例子进行解释.因此,AADL形式语义研究主要针对后两者的内容.目前,AADL形式语义描述主要采用转换的方式(translational semantics),大致可以分为两类:采用一种具有精确语义的形式语言来定义AADL语义,再依据语义进行转换;直接将AADL模型转换到另一种形式化模型.我们称前者为显式描述(explicit),可以将不精确的AADL语义形式化,能够更完整地描述语义,这种方式类似于操作语义.我们称后者为隐式描述(implicit),目的是为了直接使用语义模型的现有形式化分析工具,但这种方式有不足之处:仅仅假设转换的语义是一致的,语义描述可能不够精确;模型转换是依据AADL已有语义,而那些用自然语言和例子给出的语义不够精确,可能导致语义转换不够完整.在显式语义描述方面,文献[24]采用UML Marte对同步执行模型中周期性线程之间基于数据端口的即时与延迟通信(immediate and delayed communication)机制进行了语义描述,UML Marte具有显式的时间模型,能够同时描述逻辑时间和物理时间,方便定义线程的时间属性和通信协议.同时,AADL的通信语义本质上就是实时任务的时钟约束关系,对系统调度和可调度分析有直接的影响.但UML Marte难以支持形式化验证和分析.文献[25]则对AADL数据端口通信语义进行了描述,提出端口连接可以看作对共享数据变量的访问,采用消息缓冲区模型来定义任务之间的交互,并提出了基于共享缓冲区的分析框架,对端口通信进行优化.文献[26]则采用UML Marte对异步执行模型中事件端口通信进行语义描述,事件端口都带有队列以支持异步访问,但这样可能会导致数据或事件的传输延迟,因此该文献基于语义描述对端到端的延迟进行了分析.文献[27,28]采用动作时序逻辑描述语言TLA+(temporal logic of actions plus)对AADL执行模型的部分语义做了初步研究,包括端口通杨志斌 等:复杂嵌入式实时系统体系结构设计与分析语言:AADL 905 信、共享变量的构件间通信、抢占式调度策略以及模式的语义,但TLA+的模型检测工具分析能力不足.文献[29]采用Fiacre 和时间抽象状态机(timed abstract state machine,简称TASM)两种方法从不同角度对AADL 同步执行模型进行语义描述,并进行分析与比较.Fiacre [30]是一种能够描述实时系统行为和时间的形式化中间语言,目的是为了支持多种高层建模语言(如AADL,UML,SDL)到不同验证工具(如CADP,TINA)的建模语言的转换.TASM [31]则是抽象状态机的实时扩展,能够支持时间、资源、同步、并发等行为的描述.文献[18]采用时间抽象状态机对AADL 同步执行模型以及Behavior Annex 的语义进行形式描述,并采用UPPAAL [32]进行时间属性验证.在隐式语义描述方面,法国Verimag 实验室提出AADL 到BIP(behavior interaction priority)的语义转换[33],如AADL 线程转换到BIP 原子构件、数据端口连接转换到BIP 的连接器,仅描述了AADL 线程、进程、处理器构件以及Behavior Annex 的部分语义,采用Aldebaran 工具进行死锁、安全性的验证.BIP [34]是Verimag 提出的实时系统建模语言,采用自动机的方式描述行为,并支持异构构件之间的组合.英国Leicester 大学研究AADL 到重写逻辑Maude 语言的模型转换[35],支持行为验证,并实现了MOMENT2-AADL 工具.文献[36]研究AADL 转换到IF 语言进行形式化验证,采用Kermeta 元模型语言作为转换工具,支持静态结构、Behavior Annex 、执行模型到IF 的转换,但目前只进行了部分转换.IF 语言是Verimag 实验室提出的实时系统描述语言,扩展了通信时间自动机来描述实时系统的功能与非功能行为[37].文献[38]提出AADL 到时间进程代数ACSR(algebra of communicating shared resources)[39]的语义转换,然后进行可调度性分析,但其分析工具VERSA [40]只能支持简单的分析.文献[41]研究了AADL 到实时演算(real time calculus,简称RTC)[42]的语义转换,以支持端到端的时间延迟分析.文献[43]研究AADL 到随机Petri 网的转换.模型转换是AADL 语义描述的关键.文献[44]采用B 语言和高阶逻辑HOL(higher-order logic)形式刻画AADL 元模型,以支持AADL 模型转换的正确性.我们认为,可以采用定理证明的方式来保证模型转换的语义一致性.我们对部分AADL 形式语义描述语言进行比较,见表1.Table 1 Comparison of AADL semantics models表1 AADL 语义模型比较 Methods Fundamental formalism Verification and analysis tools StrengthsWeaknessesTLA+ Logic Model checker: TLC General and abstract expressions The verification tool support simple simulationTASM Abstract state machine Model checker: UPPAAL Analysis tool: TASMToolset Describe real time, resource and concurrency well readability Less time and data types of expressionFiacre Process algebra Model checker: TINA, CADP Offers a rich set of structuring techniques and concurrency patterns Less powerful construct, such as resource expressionMaude Rewrite logic Proving tool: ITP Analysis tool: MTT General and abstract expressions Don’t support real time descriptionBIP Automata Model checker: Aldebaran Powerful for components interaction and priority The verification tool only support deadlock detectionACSR Process algebra Analysis tool: VERSA Describe real time, resource strongly The verification tool only support simple analysisUML Marte UML None Explicit time model Don’t support formal verification AADL 能够描述系统功能行为、非功能属性以及运行时的体系结构动态演化,尤其是AADL 的可扩展性,使得AADL 建模机制越来越复杂,很多语义还需要形式化.本文认为可以对多种语义描述进行比较,从不同角度来刻画AADL 的语义与性质.2.2 AADL 建模方法的研究AADL 是嵌入式实时系统领域的体系结构设计与分析标准,而MDD 正在成为主流的开发过程.文献[45]提出AADL 与MDD 结合,能够使AADL 得到更广泛的使用.MDD 定义了3个层次的抽象:平台独立模型(platform independent model,简称PIM)、平台特定模型(platform specific model,简称PSM)以及应用代码.PIM 是模型驱动设计的初始抽象模型,是设计过程中最为重要的环节之一.因此,AADL 建模方法的研究主要涉及AADL PIM 的906 Journal of Software软件学报 V ol.21, No.5, May 2010构造.我们归纳为3类:(1) 从需求模型到AADL模型的转换由于UML,SysML,xUML(executable UML)[46],HOOD等描述语言已经广泛应用于需求的描述,因此结合这些描述语言的优势是必要的,从需求模型到AADL模型的转换就成为重要的研究内容.文献[47]采用UML作为需求模型,提出需求模型到AADL模型的转换规则,如UML类转换为AADL构件类型,类之间的组合连接转换为AADL子构件,类之间的直接连接转换为AADL端口等.Feiler提出将xUML和AADL集成到统一的模型驱动开发过程,通过一些经验规则来完成需求模型到AADL模型的转换[48],其中xUML对UML增加了更精确的执行语义.文献[49]采用SysML作为需求模型,并研究了SysML到AADL的模型转换.文献[50]则采用UML,HRT-HOOD(hard real time HOOD)[51]作为需求模型,提出将带有属性和操作的UML类图转换到AADL的包,每个包由数据构件类型、数据构件实现、子程序构件类型组成,前两者表示属性,后者表示操作,同时将HRT-HOOD的周期性对象、非周期性对象、保护对象分别转换到AADL的周期性线程、非周期性线程、数据构件,并在STOOD[15]工具中实现了这些转换.其中,HOOD是欧洲航空防务航天公司(European Aeronautic Defense and Space,简称EADS)提出的复杂系统建模方法,HRT-HOOD则是HOOD在嵌入式实时系统领域的扩展,而STOOD是建立在HOOD,AADL之上的商业建模工具.(2) AADL常用于构造系统的PSM模型,因为AADL能够同时描述系统的软、硬件体系结构,两者映射即可构成PSM模型.同时,也可以采用AADL单独建立系统的软件体系结构模型,作为AADL PIM模型.(3) 采用AADL与UML结合的方式,文献[52]基于AADL UML Profile Annex,将AADL原型(stereotype)标注在UML模型上,作为AADL PIM模型.如,构件用UML 类图表示,并标注AADL构件类型.模型驱动设计的建模一般在需求分析之后进行,为了保持需求规约与系统设计之间的一致性,可以研究基于AADL的需求建模.文献[53,54]提出了面向软件体系结构的需求工程方法,这些可以借鉴到基于AADL的需求规约当中,而且AADL V2.0的新概念将更有助于AADL直接应用于需求工程.需求阶段的AADL研究与应用,为整个生命周期提供完整的需求和概念.2.3 AADL模型转换模型转换是MDD的核心,同时也是AADL模型验证与分析的重要基础.根据嵌入式实时系统的需求,文献[52]给出了基于AADL的模型驱动开发过程:(1) 获得AADL PIM模型,如,基于AADL UML Profile Annex,将AADL原型(stereotype)标注在UML模型上,作为AADL PIM;(2) 利用功能转换规则,转换成AADL PSM;(3) 利用非功能转换规则,将PSM转换成AADL分析模型,进行可调度、性能等分析;(4) 基于正确的AADL模型转成可执行代码.模型转换关键在于转换规则及工具的研究.文献[55]对常见的模型转换方法进行了分类,按转换规则分为变量型、模式型、关系型以及逻辑型;按转换方法可以分为模型到模型的转换以及模型到代码的转换,前者包括手动转换、关系转换、图转换、结构转换、元模型转换等方法,后者则包括基于访问的转换以及基于模板的转换.在模型转换工具方面,QVT(query/view/transformation)[56]是由OMG定义的模型转换标准;ATL(Atlas transformation language)[57]是由法国INRIA开发的一种基于元模型转换方法的模型转换语言;Kermeta[58]是法国INRIA Triskel Team开发的模型转换语言,能够对元模型的结构、行为进行描述;GreAT(graph rewriting and transformation)[59]则是一种将图形转换和重写技术应用到模型转换过程中的方法.ATL和Kermeta在AADL模型转换研究中比较常用.同时,本文认为AADL模型转换的正确性验证与证明也是需要重点研究的内容.2.4 AADL模型的验证与分析在早期阶段进行体系结构验证与分析,能够尽早发现系统设计的潜在错误.目前,AADL模型验证与分析主要采用仿真和形式化方法.仿真方法需要设定体系结构模型中的初始参数,通过执行体系结构模型,对每个元素的行为进行分析与评价.ADeS(architecture description simulation)[60]是一个事件驱动的AADL行为仿真工具,支持执行时间、时限、。

一种用UML和SystemC进行嵌入式系统的系统级建模的方
法
陈科;邓馥郁
【期刊名称】《计算机光盘软件与应用》
【年(卷),期】2011(000)008
【摘要】本文用UML建模工具RationalRose设计了果蔬清洗机的嵌入式系统UML模型,然后再以UML模型为蓝本,用可执行的SystemC语言对该系统进行系统级描述.论文同时给出了系统的最终描述结果,并运行得出了仿真结果.
【总页数】2页(P174,176)
【作者】陈科;邓馥郁
【作者单位】四川职业技术学院,四川遂宁629000;四川职业技术学院,四川遂宁629000
【正文语种】中文
【中图分类】TP311.1
【相关文献】
1.结合硬件特征的UML建模方法在嵌入式系统中的应用 [J], 段义隆;刘媛媛;贺力克;刘德玉
2.基于UML和SystemC的嵌入式系统集成开发方法的研究 [J], 石柯
3.UML建模的嵌入式系统开发方法研究 [J], 周志锋;徐博;孙广富
4.基于UML的嵌入式系统系统级设计方法研究 [J], 安婧
5.基于UML-SystemC的纹理映射建模方法研究 [J], 魏美荣;田泽;吴晓成;韩立敏因版权原因，仅展示原文概要，查看原文内容请购买。