毕业论文外文翻译-CAN总线系统的实时对象调用

大连交通大学2009届本科生毕业设计外文翻译Invocation of Real-Time Objects in a CAN Bus-SystemAbstractThe paper focuses on method invocation of real-time objects in a CAN-based distributed real-time system. A simple object model is introduced, which allows the convenient modelling of hardware and software components. Related to the object model, two issues are discussed. Firstly, a model is introduced which allows to form and address object groups. This reflects a basic need in a real-time system to distribute information to multiple clients efficiently. Secondly, we discuss an approach to express timing requirements for object invocations. To achieve distributed consensus on communication resource access, an EDF-like approach is introduced, which takes advantage of knowledge about deadlines, the number of remaining communication activities, and the remaining worst-case execution time for the invoked method at each point of time.1. IntroductionFuture computer systems will, to a large extent, monitor and control real-world processes. This results in an inevitable demand for timeliness and reliability. Distributed systems which inherently provide immunity against single failures are an adequate architecture to meet the goal of reliability. Additionally, because realworld applications often require the spatially distributed control of electromechanical components, a distributed system architecture brings computing power to the points where it is needed. The availability of inexpensive yet powerful microcontrollers supports a distributed solution. This results in a system model which is composed from smart components implementing the instrumentation interface to the real world comprising sensors and actuators. A convenient way to model such an environment is to use an object-based approach where objects encapsulate all kinds of entities necessary to control a physical process. We can identify at least two layers in systems interacting with the real world. A lower responsive system level tightly controlling the sensor/actuator interface to the world and a higher system level responsible for interpretation and evaluation of the perception of the world as communicated by the instrumentation interface. In this layer, higher level decisions are performed. Although these different levels have different requirements concerning responsiveness, they are sometimes not separated clearly simply because of the hardware architecture. We concentrate on the lower system level and describe an object model which is motivated by a system structure which relies on a modular design and independent computing resources for the components of the instrumentation interface. Rather than having a central powerful processor in which electromechanical components are only modelled as objects from which control signals are generated, the electromechanical components are objects themselves powered by inexpensive microcontrollers. The objects of this layer have a well defined interface to be easily controlled by a higher level instance which can exploit this abstraction rather than dealing with low level control signals. The hardware modules are connected by a field-bus. We choose the CAN-bus (CAN: Controller Area Network), developed by BOSCH28 because it provides advanced technical features and represents an emerging standard with a wide applicability. Moreover, popular microcontrollers are available with an on-chip CAN controller. CAN is a shared bus designed to connect control systems in a spatially restricted area like cars, robots, tool machines, and other automotive or industrial automation applications. It is targeted to operate in a noisy environment with speeds of up to 1 Mbit/sec, exchanging small real-time control messages. We use the CAN message format to uniformly invoke methods on our objects. This allows a transparent object invocation in the sense that an invoking object must not know where the invoked object resides in the system. Additionally, we can address groups of objects with a single CAN message. As a common resource, the communication medium has to be shared by all computing nodes. Access to the medium has to be scheduled in a way that distributed computations meet their deadlines in spite of competition for the communication line. Since the scheduling of the bus cannot be based on local decisions, a distributed consensus about the bus reservation has to be achieved. Clearly, this is only a special case of the more general problem to schedule a cooperative distributed computation. There exist several alternative approaches to solve this problem based on the assumptions about the behaviour of the system and the environment. The first approach, known as time-triggered approach 18,21, 19 assumes a complete knowledge of all future actions of the system. Hence, during operation these systems exhibit minimal overhead paired with a maximum of predictability and are highly appropriate for safety-critical applications which can be modelled by a periodic behaviour. A more adaptable and economic way to manage system resources has to be based on run-time information. These real-time systems have to plan their operation at run-time, at least to a certain extent. Although the trade-off generally is between adaptability and predictability, these systems are scalable in the sense that they allow a coexistence of activities with different real-time requirements. These systems rely on run-time guarantees 30,11 rather than on a preplanned feasibility guarantee only. A form of calendar-based scheduling 22,30 is an approach to run-time guarantees where hard real-time activities have the possibility to reserve resources in advance. The free resources can be used by less important tasks. It should be noted that scheduling policies like e.g. earliest deadline first (EDF), least laxity first (LLF) or rate monotonic scheduling only guarantee optimality, i.e. if a schedule exists, it will be found. But in the dynamic system, there may be conflicting requests for which these scheduling policies will not find a solution. In this case they fail to guarantee anything. A calendar, on the other hand, is a mechanism to guarantee resource availability for reservations which have already been made. 2. The System Model Our system model is influenced by our anticipated hardware basis. We assume a number of different microcontrollers with different performance attributes ranging from 8Bit to 32Bit architectures. All microcontrollers are equipped with a CAN-Bus interface. We exploit the different performance and price characteristics of the microcontrollers to structure the overall task of the system into small packages. Since the simple microcontrollers are in the range of a few $s,it must no longer be a rare resource. In our application example, a simple active suspension system (Fig. 2-1),we use a simple microcontroller for each servo or complex sensor. A servo is composed from a motor and an internal sensor which provides feedback on the current position. This sensor/actuator system is connected to the CAN-bus to cooperate with other similar objects and receive control commands through CAN messages. No direct, low level control signals are visible outside the module. Thus, encapsulation and a well defined interface are supported. On the logical level, the sensor/actuator block is seen as an object on which certain methods can be invoked, e.g. to position itself to a specific angel, to communicate the angel, etc.A sensor/actuator constitutes the lowest level in the control hierarchy, comparable with a simple reflex loop in a biological system. Higher control instances are available to control groups of objects or eventually the entire system using more powerful microprocessors. Thus, the higher control instances have a well defined instrumentation interface which is composed from objects, each encapsulating a certain functionality. An object has a unique name and a set of associated operations. The unique name of the object is translated to a short form system name during run-time and maintained by a configuration service. Objects in such an environment must have some extensions to the sequential, passive model known from the field of programming languages. Particularly our model includes: 1). Active, autonomous objects. Since objects may have a dedicated processor, it is straightforward to assume a model of autonomous, active objects. An object is characterized by a name and a list of methods which can be invoked on the object. Because the object is active, it can also export information. This is equivalent to sending an invocation to another object or to a group of objects without a previous request. As described in chapter 3, we provide a transparent group communication mechanism, i.e. an object itself usually does not know whether it communicates with an object on a remote or on the local node. This group communication mechanism is a basis for remote method invocation of object groups. In fact, communication relations can dynamically be defined during run time. So, objects may join or leave a group, and are autonomous in deciding when to process a request. The concept of TMO (time-triggered message triggered object) 16 derived from the RTO.K (Real- Time Object) 17 concept enhances the conventional object model by mechanisms to specify the temporal behaviour of an object. It provides a framework to specify a complex real-time system together with its environment in the same uniform representation. The aim is an integrated design of a distributed real-time system and simulators generating real-time input modelling the target applications. A TMO exhibits active, spontaneous behaviour as well as providing services requested by a method call. Three execution models are derived for executing TMOS 17.Among them, the execution model which provides a dedicated processor for each object (Type II) is very similar to our basic system structure. The difference on the conceptual level is the notion of the object group and the fact that we do not relate spontaneous behaviour to clock events. However, if the spontaneous activity of an object is hard real-time, we also have to map it to some reserved time slot. CHAOS 11 demonstrates that the object model can be tailored to meet the efficiency requirements of realtime applications. The motivation also comes from a robotics application where electromechanical components are encapsulated and controlled by objects. CHAOS provides a spectrum of objects with different weight ranging from light weight passive objects to objects including several processes providing scheduling and synchronization facilities. The concept is targeted to rather powerful parallel machines. The active objects are too heavy weight to implement them with our simple hardware basis. In Alpha,12,objects are passive abstract data types in which a number of processes can execute concurrently. MARUTI 22 provides modules in the design process. However, these modules are broken down into elementary units (EUS) which constitute the atomic entities of sequential execution. Also, EUS resemble to objects, they are not user defined but derived during the compilation process 25. 2). Object groups. In conventional object-oriented languages a method invocation is synchronous and directed to a single object. It is usually not possible to express a request to a group of objects. However, in a real-time control system it is beneficial to provide groups of objects and to use asynchronous multicasts to invoke methods of these groups. The motivation ranges from simple and fast distribution of information, like sensor data and alarm messages, to replicated objects forming a group to achieve fault-tolerance. Because the communication medium, the CAN-Bus, supports consistent multicasts on the low system level, it is beneficial to exploit this feature. It allows to address a group of N objects with one message rather than sending N individual messages. To a certain extent, CAN provides atomicity of message transfer, i.e. either all operational nodes correctly receive a message or none of them. The consistent view of the message status between all nodes is one of the most important features of the CAN bus (cf. chapter 3).It is achieved on the hardware level by a synchronous bit transmission approach. All receivers of a CAN message (including the sender) scan the bus and analyze the current message status during the transmission of every transmitted bit. If a node locally detects a transmission failure, it immediately invalidates the current message by intentionally producing an detectable error on the bus. Every node including the sending node now is aware that the message transfer failed. Automatically, the sender will eventually retransmit the message. If no transmission error is detetcted, all operational nodes have received and accepted the message. A more detailed description of this feature and its exploitation for atomic group communication is given in 1428. The basic inter-object communication in systems like JAVA and CORBA focus on a point-to-point communication., there are some one-to-many communication methods in JAVA like the observable/observer class 1 or recently, the iBus 24.Both mechanisms are based on a explicit registration of clients at the server which differs significantly from a general group communication mechanism which is a many-to-many communication paradigm. The transparent communication mechanism used e.g. in MARUTI 25 enables the objects to use a send primitive without specifying the receiver(s).This is done by specifying the communication channel bindings in the MARUTI configuration language (MCL).The goal is to separate functional and non-functional issues. However, the binding is performed during compile time. No dynamic changes of the communication relations are possible. The communication model which we adopt is similar to that of autonomous decentralized systems (ADS) 26.In this model, software subsystems autonomously manage themselves and coordinate their activities with other subsystems. This coordination is achieved by the data field, which represents global information. The autonomous entities can extract relevant information from the data field. Based on this mechanism, groups of objects, sharing a subset of the global information, can be constructed. In order to support real-time object groups with consistent information, the group communication protocol must deliver real-time messages to all members of a group both timely, and in a consistent order. In section 4 we describe how to guarantee timely multicast delivery by exploiting the CAN bus arbitration mechanism. Given the guarantee of timely message transmission, we have also shown in 15 that the deadline can be used to consistently order hard real-time multicast messages. 3). Use of time information. Objects must have some notion of time to express execution times of their methods, deadlines, and slack time. In a dynamic real-time system, on-line scheduling decisions are based on these assumptions which therefore must be available at run-time.The temporal behaviour of the object must be specified, verified, and monitored. An approach to bind time information to object classes and monitor the temporal behaviour of the system is described in 10.It is planned to use these mechanisms to specify and monitor the temporal behaviour of the system. In this paper, however, we only describe the use of time information for the dynamic reservation of the bus resource.CAN总线系统的实时对象调用摘要本文方法是在CAN-based分布式实时系统中调用一个简单的实时对象,从而方便允许硬件和软件组成相关的对象模型的造型，共讨论了两个问题。首先，一个模型，可以形成和地址对象组，这反映了一种基本实时系统需要多客户有效分配信息。其次，我们讨论表达定时要求为对象invocations实现分布式共识的方法,通信资源访问EDF-like算法，利用知识的剩余期限、交流活动，剩下的时间为调用方法用在每点的时间。1介绍未来的计算机系统,在很大程度上, 这个结果必然要求监测和控制实际过程,及时性和可靠性分布式系统的固有免疫，对抗单一故障提供适当的架构去提高这个目标的可靠性。此外,因为realworld往往需要空间应用机电元件、分布式控制系统结构构建一个分布式计算能力的平台便宜但有力的支持分布式解决方案。至此构成了系统模型从智能组件的仪器设备接口,实现真实世界由传感器与执行器这样一种便捷的方法，是使用环境object-based方法在各种各样的实体对象封装需要控制的物理过程。我们可以辨别至少两层系统相互作用。利用一个较低的水平紧紧控制响应系统传感器/驱动器接口, 在这一级系统和更高的系统负责解释和评价传感器所传达的仪器接口信号,来进行更高层次的决定。虽然不同层次有不同的要求,他们有时是简单的相关性与清晰的硬件结构,因为我们把注意力集中在较低的系统级和描述对象模型,该模型是由一个系统结构,靠模块化设计和独立的计算资源的仪器接口元件而不是一个中央处理器,机电组件强大的功能,控制信号的生成、机电组件对象本身是由廉价微控制器，这一层的对象有良好定义接口，从而可以利用由上级实例实现这个抽象控制，而不是处理低水平的控制信号。我们选择了由CAN总线连接的硬件模块应用 (CAN:控制器局域网,由博世28,因为它提供先进的技术特点和代表了一种新兴的标准和适用性，而且新兴的单片微控制器可与CAN控制共享总线控制系统，设计连接一个空间限制区域,如汽车、机床、机器人及其他汽车或工业自动化应用。它是针对在嘈杂环境中运行的速度可以达到1 Mbit /秒的系统,交换小实时控制信息。在某种意义上我们用能报文格式统一调用方法对我们的对象进行一个透明的对象调用, 此外在这个系统，一个调用对象必须随机从CAN调用对象,我们可以解决组对象单一CAN通信。作为一种资源,交流媒介必须分享计算的节点。访问中已经被安排在一种分布式的计算，以满足他们的最后时间,尽管自从调度的汽车无法立足于本地决策的通信线路竞争共识, 显然一个分布式的公共汽车的定座已达到,这仅仅是一个特殊的例子，更一般的安排一个合作的分布式解决计算的问题。基于假定系统的行为模式和环境，CAN选择几种可供的途径来解决这个问题,。第一种方法,称为time-triggeredd,m.北京:21,m.北京:19的假设未来的一个完整的知识行为的系统。因此,这些系统运行过程中,有轻微的开销用于最大的可预见性和高度适合紧急安全程序,可以由一个周期解决。在一定程度上，这些实时系统运行计划运行时，一个更强的适应性和经济的方式来管理系统资源必须基于实时信息。虽然通常是平衡的，但这些系统的适应性和可预见性是可伸缩的,也就是说它们允许共存的活动与不同的实时要求。这些系统依靠实时保证30,11,而不是在只有一种calendar-based调度的可行性保证 22,30是一种在即时活动运行时保证有可能提前预定的资源。应该指出可以用较少的重要任务调度政策，如最早的期限第(EDF),至少松弛第一(LLF)或率，只有保证最优、初始调度计划:如果存在,它将会被发现。但是在这个动态系统,可以有矛盾的要求, 在这种情况下这些调度的政策将找不到解决办法,他们无法保证任何东西都在一个时间内,另一方面, 已经预订一种机制来保障资源可用了。2这个系统的模型我们的系统模型是受我们的预期的硬件基础限定的，我们假设许多具有不同的性能和特征的不同的微控制器,从8Bit 32位架构所有的微控制器配备应用界面，我们利用不同的性能和价格的微控制器结构特点, 在简单的微控制器的一些$ s系统的总体任务被分成小块, 在我们的应用实例它必须不再是一种稀有资源,简单的主动悬架系统(图1 - 2),我们用一个简单的单片机为每个伺服或复杂的传感器伺服电机组件，从内部传感器对当前位置提供反馈。该传感器/制动器的应用系统连接合作和其他类似的对象,通过控制指令能收到消息没有直接的、低水平的控制信号,以及CAN以外的模块。因此, 在某种方法下封装和定义的接口，在逻辑层次、传感器/驱动器块被视为同一个物体时可被调用，例如把自己定位到一个特定的天使,天使、交流等构成一个最低水平的传感器/驱动器,可控制的层次类似一个简单的反映在生物系统的循环。因此更高的控制情况下，可用来控制群体的系统或最终整个系统更强大的微处理器,在控制情况下有很明确的仪器接口组成的系统,各自代表某个功能。每个对象都有一个独特的名字和一组相关的操作及独特的名称相对应，在运行时转化为一个短的形式系统的名字,保持在一个配置服务内，在这样的环境下系统必须有一些从被动模式的编程语言延伸到顺序，尤其是我们的模型，包括:(1)主动、自动控制类自从信号拥有专用处理器,它便是直接假定一个模型的自主,激活一个对象的特点，即一名和一系列的方法,但可被调用的对象应该是灵活的，它也可以发出信号，这相当于从一个对象调用到另一个对象，或发送到一组没有先前要求的对象。在第3章，我们提供一个透明的群体沟通机制，即被控对象本身通常不知道它是否与系统在一个遥远的地方通信。事实上这个小组远程调用沟通机制是系统关系协调的基础，沟通关系可以被定义在动态运行时间里，所以信号可以加入或者留到下一组, 当处理一个请求时可自主决定。这个概念(time-triggered消息引发的对象)16来自RTO.K(真实的-时间对象)5的概念,以提高常规对象模型到指定行为机制的对象的时间，它提供了一个以指定一个复杂的实时系统与环境框架, 在相同的统一表示中，这个目标是一个活跃的一个完整的设计和仿真生成分布式实时系统的实时输入造型目标程序，自动运行以及提供服务的方法及调用要求。三个执行模型为执行TMOS17。其中, 我们的基本体系结构的执行模式，为每个对象提供非常相似的一种专用处理器 (II型)。概念层次上的区别物体的想法,我们集团不涉及自发行为的时钟事件，然而如果自发活动对象是即时的,我们也将给一些保留时间段。11的混乱表明对象模型可定制的要求，来满足实时应用效率。这个动机也来自一个机器人应用中机电组件封装和控制的对象，提供了一种谱混乱的物体和重不同的对象范围，从轻的物体包括几个被动过程提供了调度和同步设施，这个概念是针对相当强大的并行。这个活动是用我们的简单的硬件基础进行庞大的系统实施。在阿尔法,12,对象是被动的抽象数据类型,大量的过程可以并行执行22,MARUTI提供模块设计过程。然而,这些组件分解为基本单位(EUs)构成了顺序执行的原子单位。同样,EUS像对象,他们不是用户定义的,但在编译过程中被推导出来的25。(2)对象组在传统的面向对象的语言中，调用同步和指向一个单独对象的方法通常是不可能去表达一群对象,然而在实时控制系统却是有益的,为用户提供团体使用异步multicasts对象调用的方法,这些团体简单、快速分布的信息,如传感器数据和报警信息,复制对象形成一组信息来达到容错效果，由于传播媒介、应用、一致支持multicasts的低水平,这是有益的系统开发，这一特点允许地址的一组信息传送一个讯息,而不是个人短信发送N 个地方。在某种程度上,可提供的讯息传递,使表面或所有运营节点接收信息或拒绝信息。这个一致的观点是cf. CAN总线(第3章)之间的所有节点消息的现状的重要特征,是由硬件实现同步点水平传输方式所有接收器的信息(包括发送者可以在公共汽车和分析)扫描当前信息在每传送点传播的位置，如果一个结点局部侦测传输失败，它立即invalidates当前信息检测并在公共汽车上每个节点产生一种错误的信号,包括发送现在知道消息传送失败自动发送的消息最终停止如果没有传动误差detetcted,所有操作节点和接受信息将会收到。对其开发原子群体沟通更详细的描述请参照14,m.北京:28。通信系统的基本inter-object，如JAVA和CORBA集中到一个点到点的通信，有一对沟通的方法,如在爪哇的可见/观察者类1和m.北京:最近,iBus 24。两种机制都基于一个明确的注册用户在服务器端的不同于一般的群体沟通机制,两者都是一种沟通的范例。透明的沟通机制在于MARUTI25使物体送至原始位置而并没有具体的接收器(s),这是在指定的通信信道中绑定MARUTI配置的语言(产),目标是分开的功能性及非功能性问题。然而，在编译时没有动态变化的沟通关系是不可能的。我们的通讯模型采用类似于分散式系统(广告)自治区26。在该模型中,自主管理软件子系统和协调他们与其它子系统的活动。这种协调实现数据的字段,代表着全球信息。这个自治实体可以从基于这一机制、组织的数据字段提取相关信息, 可以建造一个共享全局信息的子集。为了支持实时集团，集团必须提供以一贯的信息为基础的即时消息通讯协议，所有的成员都在一个一致的秩序里，在第四节我们将描述如何保证及时交货，利用多CAN总线的仲裁机构给出了保证及时的信息传输，我们也显示在15的期限，可以用来为实时多播的讯息持续努力。(3)时间控制信息物体必须有一些时间来表达他们的方法,执行时间期限,和松弛时间。在一个动态实时系统、在线排序中的决定都基于这些假设,因此必须能够满足实时运行。时间的行为的对象必须明确、审核和监控，一种绑定一次信息并监控对象分类系统的时间行为描述了10. 它是打算用这些机制来指定时间和监控系统的行为。然而