嵌入式系统的网络服务器——外文文献翻译
嵌入式系统英文
Implementation and Evaluation for Sophisticated Periodic ExecutionControl in Embedded SystemsYuuki Furukawa, Toshihiro Yamauchi and Hideo Taniguchi Graduate School of Natural Science and Technology, Okayama Universityfurukawa@swlab.cs.okayama-u.ac.jp, {yamauchi, tani}@cs.okayama-u.ac.jpAbstractEmbedded systems are complicated, and a large number of these systems are widely used today. In embedded systems, the types of processings to be executed are limited, and many processes are executed periodically. In such systems, we need to reduce the overhead of periodic execution control and the dispersion of the processing time. ART-Linux has been proposed as a conventional real-time operating system that can be used for this purpose in various devices such as robots. In this paper, we discuss the periodic execution control of ART-Linux and clarify several problems. Next, we propose a design for sophisticated periodic execution control in order to solve these problems. In addition, we discuss the realization of periodic execution control, and the effects of the proposed control. Finally, we show the results of our evaluation for the release and the wait to clarify the effects of the proposed control.Keywords: P eriodic execution control, Scheduling, ART-Linux, Control overhead, Real-time process1. IntroductionEmbedded systems are complicated, and a large number of these systems are widely used today [1]. Therefore, it is important to upgrade the software that controls the resources of the embedded devices. In embedded systems, the types of processings to be executed are limited, and many processes are executed periodically. An example of such a process is a process that controls the motor of a robot; this process needs to be executed every 5 ms. Such a process must be executed before a deadline, and this is an example of real-time processing. In this case, we need to reduce the overhead of the periodic execution control and the dispersion of the processing time.ART-Linux [2][3][4] has been proposed as a conventional real-time operating system that can be used in devices such as robots [5]. In ART-Linux, we can use the application program (AP) and the device driver for Linux, the real-time process with the short period can be periodically executed without significant jitter. There have been studies related to the improvement of the performance of ART-Linux [6].In this paper, we discuss the periodic execution control of ART-Linux and clarify several problems. Next, we propose a design of a sophisticated periodic execution control to solve these problems. In addition, we discuss the realization of periodic execution control, and the effects of the proposed control. Finally, we present the evaluations of the control overhead and the dispersion of the processing time to clarify the effects of the proposed control.2.1. Periodic Execution ControlART-Linux is a real-time operating system based on Linux. We refer to processes executed periodically as real-time processes; all other processes are termed non-real-time processes.ART-Linux manages real-time processes and non-real-time processes separately. Real-time processes have a higher priority than non-real-time processes. That is, non-real-time processes are executed only when there are no real-time processes to be executed.We show the periodic execution control of ART-Linux in figure 1. The ready queue in figure 1 manages the real-time processes that are in a ready state so that the processes can be executed on the basis of priority. We call this the ready state. The wait queue manages the real-time processes that are in a wait state. We call the transition from the wait queue to the ready queue a release. In the next few paragraphs, we explain the processing of the periodic execution control of ART-Linux.1. RegisterWhen a non-real-time process requires registration, this process is connected to the ready queue. Consequently, it is managed as a real-time process. This real-time process is assigned a period and a priority.2. ExecuteIf there is already a real-time process in the ready queue, the real-time processes are executed on the basis of their priorities.3. WaitA real-time process requires a wait when the processing of the real-time process for oneperiod is finished. Then, this real-time process is disconnected from the ready queue, connected to the wait queue, and set a waiting time. The waiting time is the time from the next release time of the real-time process before this one in the wait queue to the next release time of this real-time process. In this way, the real-time process waits until its next release time.4. ReleaseAt the time of a timer interrupt, the waiting time of the real-time process at the top of the wait queue is calculated. If the resulting value is less than 0, the real-time process is disconnected from the wait queue and connected to the ready queue. Then, the waiting time of the next real-time process in the wait queue is calculated, and the release of this real-time process is judged. The above step is repeated until the waiting time after calculation is greater than 0 or until all real-time processes are disconnected from the wait queue. In other words, the above step is repeated until all real-time processes reaching a release time are connected to the ready queue.5. UnregisterWhen a real-time process requires unregistration, this process is disconnected from the ready queue and managed as a non-real-time process. Then, its period and priority are initialized.2.2. Performance2.2.1. Measurement environment and items: We measured the processing time from the timer interrupt to the execution of a real-time process to clarify the periodic execution control overhead in ART-Linux. Further, we measured the interval error of the periodic execution to clarify the precision of the periodic execution control. An interval of the periodic execution is the time from a processing start time to the next processing start time for a real-time process. In addition, the interval error is the difference in value between an interval and the period of a real-time process. We list the measurement environment in table 1. We used the rdtsc instruction to record the time.2.2.2. Time from timer interrupt to execution of real-time process: We registered one real-time process with a period of 1 ms and the maximum priority and measured the time from the timer interrupt to the execution of this process 100 times. This result is shown in table 2, and the distribution of the time is shown in figure 2.The difference between the average values and the maximum values is considerably larger than the difference between the average values and the minimum values in both table 2 and figure 2. We speculate that the dispersion of the time from the timer interrupt to the execution of the real-time process is large. One reason for this may be the fact that the processing time for the release is proportional to the number of real-time processes to be released at the same time, and the time from the timer interrupt to the execution of the real-time process increases. Therefore, we believe that the precision of the periodic execution will be low.2.2.3. Measurement of interval of periodic execution: We registered one real-time process with a maximum priority and measured the interval of periodic execution. We set theexecution in each case. The interval error is shown in figure 3; we have explained it below.The interval error of the periodic execution is proportional to the period shown in figure 3. We measured the precision of the timer interrupt period to clarify this factor. As a result of the measurement, we found that the actual timer interrupt interval is approximately 0.996 ms for the timer interrupt interval of 1 ms. Therefore, there is approximately 0.4% error for the timer interrupt interval. In figure 3, the interval error of the periodic execution is approximately 4 µs for a period of 1 ms. That is, this error is affected by the error of the timer interrupt interval. In addition, we speculate that the timer interrupt does not occur by a correct period because of the difference between the timer interrupt period that the system requires and the precision of the timer movement clock.2.3. ProblemsWe will discuss five problems to be clarified by the processing of the periodic execution control and the result of the measurement in ART-Linux.1. The control overhead for a release is proportional to the number of real-time processesscheduled to be released at the same time, and the dispersion of the processing time for the release is considerable.For the release at the time of the timer interrupt in ART-Linux, the waiting time for a real-time process at the top of the wait queue is calculated, and the release of this process is judged. Then, all real-time processes scheduled to be released at this time are disconnected from the wait queue and connected to the ready queue. Therefore, the control overhead for the release is proportional to the number of real-time processes scheduled to be released at the same time. Therefore, if there are a considerable number of real-time processes scheduled to be released at the time of the timer interrupt, the processing time for the2. The control overhead of the connection processing to the wait queue for the wait isproportional to the number of real-time processes, and the dispersion of the processing time for the wait is considerable.For the wait of a real-time process in ART-Linux, the wait queue is searched from the top to calculate the waiting time of a real-time process that requires a wait and decide a position to insert this process into the wait queue. Therefore, processing that is proportional to the length of the wait queue is required; the control overhead for the wait is affected by the number of real-time processes and the waiting time of each real-time process in the wait queue. For example, if there are a considerable number of real-time processes that are released earlier than the real-time process that requires a wait, the processing time for the wait is significant. Hence, the processing time for the wait is long, and the dispersion of this processing time is considerable.3. A real-time process that is not completely processed before the next release time has anadverse effect on the other real-time processes.Let us consider a case in which a real-time process is not completely processed before the next release time of a periodic execution control. Such a real-time process changes the interval of the periodic execution of the other real-time processes, and the precision of the periodic execution becomes low. In figure 4, process B is an example of such a real-time process. When process B requires a wait in ART-Linux, it waits from this time to the next release time. In this case, process B waits until the release time of t2 not t1. In other words, even if process B is not executed periodically on the basis of its period, the execution of this process continues periodically. Process B uses the time when process A is feasible, and the interval of the periodic execution of process A changes.4. The dispersion of time from the timer interrupt to the execution of a real-time process issignificant.As shown in Section 2.2.2, there is a case in which the change in the time from the timer interrupt to the execution of a real-time process is considerable. If such a change in time is big, the precision of the periodic execution is low. One of this reason is that the dispersion of the processing time for the release is significant.5. A difference in the clock precision between a timer and a processor is not coordinated.As shown in Section 2.2.3, the interval error of the periodic execution is proportional to the period and increases because there is a difference in the clock precision between a timer and a processor. If the difference between the period and the interval of the period execution is considerable, the precision of the periodic execution will be low.3. Sophisticated periodic execution control3.1. DesignThe processing time of the release and the wait for the periodic execution control of ART-Linux are affected by the number of real-time processes, and the dispersion of those processing time is significant. This results from the waiting time of a real-time process. Therefore, the sophisticated periodic execution control that we propose manages the real-time process scheduled to be released with respect to the time of each timer interrupt without managing the real-time processes that need to wait in one queue. Therefore, the proposed control can solve four of the five above-mentioned problems for the periodic execution control in ART-Linux.In figure 5, we show the schematic representation of the sophisticated periodic execution control that can solve problems 1–4 of ART-Linux. The control can be explained as follows: The execution management table in figure 5 is equivalent to the ready queue shown in figure 1, and the periodic control table is equivalent to the wait queue.particular, it manages the release element of the real-time process to be executed by connecting it to the entry of the execution management table on the basis of the priority of the real-time process. The release element is the element that has the information of the real-time process and has two queue entries. These entries are used for connecting the real-time process to the execution management table and the periodic control table. The periodic control table manages the real-time process scheduled to be released each time; the number of entries is equivalent to the longest period that can be set. One entry in this table is equivalent to one timer interrupt and is connected to the release element of the real-time process to be released at the timer interrupt. In other words, the number of entries in the periodic control table should be the least common multiple of the periods for all real-time processes.We explain the processing of the sophisticated periodic execution control below.1. RegisterWhen a non-real-time process requires registration, this process is managed as a real-time process by the periodic control table. Then, the periodic control table is searched, an entry that is connected to few release elements in the periodic control table is found, and the release element of the real-time process is connected to this entry. Simultaneously, the real-time process is set a period and a priority.2. ReleaseAt the time of the timer interrupt, the current entry is translated to the next entry. The current entry is the entry that corresponds to the time of the timer interrupt in the periodic control table. If there is a release element in the current entry, the decision to release a real-time process is taken. In particular, the release element is connected to the execution management table on the basis of the priority of the real-time process. Then, the release element is not disconnected from the periodic control table. If the priority of the real-time process to be released is greater than that of the current process, a pre-emption occurs. In addition, if there is a release element of the real-time process to be executed in the execution management table at this time, all release elements of this real-time process are disconnected from the execution management table and the periodic control table, and this real-time process is terminated. This is done to restrain the adverse effect that this real-time process has on the other real-time processes.3. ExecuteAfter the processing of release, wait, and unregister, if there is a release element in the execution management table, real-time processes are executed on the basis of their priorities. Then, the release element is not disconnected from the execution management table. Therefore, there is a release element of the real-time process being executed at the top of the entry corresponding to the priority of the execution management table. A bitmap is used for deciding which entry should be connected to the execution management table.4. WaitWhen a real-time process requires a wait, its release element is disconnected from the periodic control table. Therefore, the real-time process waits until the next release time.5. UnregisterWhen a real-time process requires unregistration, all release elements of this process are disconnected from the periodic control table. Then, the period and the priority of this process are initialized. Hence, this process is managed as a non-real-time process.3.2. CharacteristicsThe sophisticated periodic execution control that we proposed in Section 3.1 has the following characteristics:1. The release of the real-time process is managed by the periodic control table.2. A release element has two queue entries that are used for connecting the release element tothe execution management table and the periodic control table.3. A real-time process that is not completely processed before the next release time isterminated.4. When the release element is connected, the dispersion for the number of release elementsconnected to each entry of the periodic control table becomes low.According to characteristic 1, the calculation of the waiting time is unnecessary. Because of characteristic 2, the processing of the disconnection from the periodic control table for the release and the processing of the connection to the periodic control table for wait are unnecessary. Furthermore, because of characteristic 1 and 2, the number of queue operations required decreases, and the control overheads for the release and wait become small. In addition, we have speculated that the dispersion of the processing time for the release and wait become small because the number of processing for searching the release element is few. Because of characteristic 3, the influence of a real-time process that is not completely processed before the next release time on the other real-time processes is restrained. Because of characteristic 4, the dispersion of the processing time for the release becomes small.3.3. Realization3.3.1. Data structure: We have realized the sophisticated periodic execution control that we proposed earlier. We show the data structure of this periodic execution control in figure 6 and explain each management table below. The data structure of the periodic execution control has six management tables.real-time processes with the periodic control table. The current entry (curpointp) is translated into the next entry at every timer interrupt. Pct is the pointer to the top of the periodic control table, and pctsize is the number of entries in the periodic control table.The number of entries in the periodic control table is the least common multiple of the periods of all real-time processes. Each entry manages the release element. All release elements that are connected with the entry to which curpointp points, (current entry) are connected to the execution control table for the release. The count of the periodic control table is the number of release elements to manage.The release element contains information on the real-time process. Next is used for connecting the release element to the periodic control table, whereas prinext is used for connecting the release element to the execution management table. Procp is pointer to the real-time process.The execution management table manages the release elements of the real-time processes that are to be executed on the basis of their priority. In this table, the release element of the real-time process being executed is at top of the entry that has the maximum priority among the entries that release elements are connected.The real-time information table manages the period and the priority of the real-time process. The number of each entry is equivalent to the process identifier. If the process management table manages the period and the priority of the real-time process, the access time may increase because the process management table has a considerable amount of information. Therefore, the cache miss is restrained, and the access time required to use the real-time information table becomes short. When a real-time process is registered, rflag is set a period and rpri is set a priority. If the real-time process is released, the most significant bit of rflag is set. Further, when the real-time process requires a wait, this bit is reset.number of unused release elements, and maxnum is the number of all release elements that are allocated at the time of the initialization of all management tables.3.3.2. Coding:Bear in mind the following for the implementation of the sophisticated periodic execution control.First, the optimization of the code and the use efficiency improvement of the register used in the method are required in order to speed up processing. For example, we summarize the cords handling the same variable in one place in order to reduce the amount of rewriting in the register. As a result, the processing time becomes short.Many release elements may be used by a real-time process in the proposed control. Therefore, the quantity of data to be referred to during one processing may become considerable, and the cache miss rate may become high. Moreover, the access time may increase significantly because the data spatial locality becomes low. Therefore, when the sophisticated periodic execution control is implemented, it is necessary to devise how to handle data such as the period and the priority of the real-time processes and how to allocate the release element.Hence, we reduce the quantity of data for a real-time process and minimize the quantity of data for a release element. Further, during the processing of the release and the wait, data that do not relate with the periodic control are not read. The release element has only two queue entries and a pointer to the process. Information related to the real-time process, such as the period and the priority, is described in the real-time information table. This is done to avoid giving the information of the real-time process in the process management table and to reduce the quantity of data that is accessed. If the process management table contains the information of the real-time process, the quantity of data that needs to be accessed increases considerably because the process management table has a significant amount of information. Moreover, the state of the real-time process as ready or wait is contained in rflag. We can use the same entry to manage the period and the state of the real-time process because the period of the real-time process is only changed in the processing of registration or unregistration. Therefore, we can reduce the quantity of data accessed, and the cache miss rate becomes low.Figure 7 shows how to allocate release elements in the control that we have realized. At the initialization of each management table, release elements are allocated according to the maxnum size. Let x be the value that is obtained by dividing maxnum by pctsize. “i” is the serial number of each entry in the periodic control table. When the release element is connected to the i-th entry, the unused release element to use is searched from the (x * i)-thentry of all release elements. Therefore, the release element for each entry in the periodic control table is accumulated in the memory. Therefore, the data spatial locality is improved, and the access time for the release and wait decreases.3.4. EffectsWe have described the effects of the sophisticated periodic execution control below.1. The control overhead of the release becomes small.For the release of a real-time process in ART-Linux, the waiting time for all real-time processes scheduled to be released at the same time is calculated; then, these processes are disconnected from the wait queue and connected to the ready queue. On the other hand, in the proposed control, the current entry is translated into the next entry, and all release elements of the current entry are connected to the execution management table. Therefore, it is unnecessary to calculate the waiting time and to disconnect the real-time processes from the wait queue. Moreover, the number of processing that is influenced by the number of real-time processes scheduled to be released at the same time decreases, and the dispersion of the processing time for release becomes small.2. The control overhead of the wait becomes small, and the dispersion of the processing timefor the wait becomes small.For the wait of a real-time process, in ART-Linux, the wait queue is searched from the top, and the waiting time for the real-time process that requires a wait is calculated. Then, the real-time process is disconnected from the ready queue and connected to the wait queue.On the other hand, in the proposed control, the release element is only disconnected from the execution management table. In addition, the release element of the real-time process being executed is at the top of the entry with its priority. Therefore, the processing time for the wait is short, and this value is fixed without affecting the number of the real-time processes in the wait queue and the waiting time of each real-time process.3. The adverse effect of a real-time process that could not be completely processed before thenext release time on the other real-time processes is restrained.In ART-Linux, the execution of the real-time process continues periodically even if the execution is not completed before the next release time. On the other hand, in the proposed control, if there is a release element of the real-time process still to be executed in the current entry as a release at the next release time, this real-time process is terminated. In other words, a real-time process that is not completely processed before the next release time is terminated. Therefore, the influence of such a real-time process on the other real-time processes is restrained.4. The dispersion of the processing time for the release is small.In the proposed control, for registration, when the release element is connected to the periodic control table, the periodic control table is searched, an entry managing few release elements in the periodic control table is found, and the release element of the real-time process is connected to this entry. Therefore, the dispersion for the number of release elements being connected to each entry of the periodic control table becomes low. Hence, when there are real-time processes with different periods, the dispersion of the processing time for a release becomes small. As a result, the dispersion of the time from the timer interrupt to the execution of a real-time process becomes small.974. Evaluation4.1. AnT operating systemWe have implemented and evaluated the proposed control in AnT [7][8]. AnT is an operating system based on microkernel architecture. The basic architecture of AnT is shown in figure 8. The program consists of OS and service. The OS comprises the kernel, which is called as the internal core, and the external core, which is executed as processes (OS server). Service consists of AP processes that execute the applications program. The internal core is the program part that guarantees the execution for a minimum number of common functions in all the systems. As the main function, the internal core has functions of scheduling management and memory management. The external core is the necessary program part to adapt to the use cases of the systems, it has a dynamically reconfigurable structure. For example, AnT offers the functions of input/output control, file management, and device driver as processes. Service is the program part that offers services.AnT has the following characteristics: fast inter-server program communication mechanism, process control mechanism for dynamic running mode switch, adaptive-control function, and dynamic OS server replacement mechanism. The fast inter-server program communication mechanism offers high-speed communication control using copy-less data transfer, protection of the transfer data and provision of interface that adapted to the use case of the systems [8]. The dynamic running mode switch mechanism is mechanism that can switch the running mode of a process dynamically and freely. The adaptive-control function dynamically changes the software function and structure to adapt to the use case of the system. The dynamic OS server replacement mechanism allows us to continue the service without stopping the operating system when the OS server is extended or when the OS server is malfunctioning.4.2. Evaluation itemsWe have clarified the effects of the proposed control by comparison of AnT and ART-Linux. We evaluated the following.1. The processing time of the release when there are a large number of real-time processesscheduled to be released at the same time2. The processing time of the wait when there are a large number of real-time processes inthe wait state3. The dispersion for the number of real-time processes to be released at the same time98。
IT翻译
Unit one1. A computer is a fast and accurate system that is organized to accept, store and process data, and produce results under the direction of a stored program.计算机是一种快速而精确的系统在存储程序的指导下它是有组织的接收存储和处理数据以及输出结果。
2. like input devices, output devices are instruments of interpretation and communication between humans and computer systems.类似与输入输出设备是人类和计算机系统之间阐述和交流的工具。
3.This means that, in its network server role, the computer is responsible for holding the files and managing the processes that enable everyone in the office to access and use the network.也就是说，在网络服务器的角色中，计算机负责保管文件以及管理着使每个人在办公、公司里能够访问和使用网络的过程。
Unit two1.Like the Macintosh operating environment, Windows provides agraphical user interface (GUI), virtual memory management, multitasking, and support for many peripheral devices.像苹果公司的MAC机的操作环境，窗口提供了一个图形化用户界面，虚拟内存管理进行多任务工作和支持多种外围设备。
嵌入式系统专业术语中英文对照
BMC:Burst Mode Controller 突发模式控制器
BMS:Building Management System 智能建筑管理系统
BRI:Basic Rate ISDN 基本速率的综合业务数字网
BS:Base Station基站
BSC:Base Station Controller基站控制器
CDDI:Copper Distributed Data 合同缆分布式数据接口
CDES:Carbon dioxide extinguisbing system 二氧化碳系统
CDMA:Code Division Multiplex Access 码分多址
CF:Core Function 核心功能
CFM:Compounded Frequency Modulation 压扩调频繁
AF:Acoustic Feedback 声反馈
AFR:Amplitude /Frequency Response 幅频响应
AGC:Automati Gain Control自动增益控制
AHU:Air Handling Unit 空气处理机组
A-I:Auto-iris自动光圈
AIS:Alarm Indication Signal 告警指示信号
DWDM:Dense Wave-length Division Multiplexing 密集波分复用
DXC:Digital Cross-Connect 数字交叉连接
E:Emergency lighting照明设备
E:Equalizer 均衡器
E:Expander 扩展器
嵌入式系统外文翻译译文
嵌入式系统嵌入式系统是一种设计用来执行一种或几种功能的实时计算机系统。
它被嵌入于一个完整的包括硬件和机械装置的设备中。
与传统计算机，例如个人电脑相比，他的设计更灵活应用更广泛。
在今天由嵌入式系统控制的设备很普遍。
历史第一个被大家认可的现代嵌入式系统是麻省理工学院仪器研究室的查尔斯·斯塔克·德雷珀开发的阿波罗导航计算机。
在两次月球飞行中他们在太空驾驶舱和月球登陆舱都是用了这种惯性导航系统。
在计划刚开始的时候，阿波罗导航计算机被认为是阿波罗计划风险最大的部分。
为了减小尺寸和重量而使用的当时最新的单片集成电路加大了阿波罗计划的风险。
第一款大批量生产的嵌入式系统是1961年发布的民兵I导弹上的D-17自动导航控制计算机。
它是由独立的晶体管逻辑电路建造的，它带有一个作为主内存的硬盘。
当民兵II导弹在1966年开始生产的时候，D-17由第一次使用大量集成电路的更新计算机所替代。
仅仅这个项目就将与非门集成电路模块的价格从每个1000美元降到低了每个3美元，使集成电路的商用成为可能。
民兵导弹的嵌入式计算机有一个重要的设计特性：它能够在项目后期对制导算法重新编程以获得更高的导弹精度，并且能够使用计算机测试导弹，从而减少测试用电缆和接头的重量。
这些二十世纪六十年代的早期应用，使嵌入式系统得到长足发展，它的价格开始下降，同时处理能力和功能也获得了巨大的提高。
英特尔4004是第一款微处理器，它在计算器和其他小型系统中找到了用武之地。
但是，它仍然需要外部存储设备和外部支持芯片。
1978年，国家工程制造商协会发布了可编程微控制器的“标准”，包括几乎所有以计算机为基础的控制器，如单片机，数控设备，以及基于事件的控制器。
随着微控制器和微处理器的价格下降，一些消费性产品用使用微控制器的数字电路取代如分压计和可变电容这样的昂贵模拟组件成为可能。
到了二十世纪八十年代中期，许多以前是外部系统的组件被集成到了处理器芯片中，这种结构的微处理器得到了更广泛的应用。
外文翻译---NET Compact Framework嵌入式系统中的随机控制协议(CRP)
翻译部分英文原文Performance of the Controlled Randomness Protocol on .NET Compact Framework Embedded SystemsAbstract—The Controlled Randomness Protocol (CRP) for management of cryptographic keys is a method to improve the security level of secure communication protocols. We assess the performance of the CRP when implemented on embedded systems running the .NET Compact Framework. We present our findings from two different platforms: one smartphone running .NET Compact Framework 3.5 and one smartphone running .NET Compact Framework 4.0. Our assessment verifies that when implemented in the .NET Compact Framework, the controlled randomness protocol imposes a configurable and tolerable amount of overhead computation while it offers a significant security improvement compared to a conventional implementation of a key management protocol.I. INTRODUCTIONIn real world applications of cryptographic protocols, the key management problem refers to the life cycle management of cryptographic keys. It includes the necessary operations for key generation; distribution; storage; replacement and exchange; usage; and destruction [1]. In order to retain a specific security level, keys used in cryptographic algorithms and protocols must be periodically refreshed i.e., new keys are exchanged between communicating parties and old keys are replaced. These precautions ensure that only a specific amount of information is encrypted under the same key and thus, the exposure of information is minimized in case a key is leaked.Key agreement is the process by which two or more parties agree on a common cryptographic key for a specific timeframe. Key transport is the process by which the agreed key is transferred to the participants. In many scenarios, the two processes occur simultaneously: the participants exchange information by which they both set and exchange the key(s) to be used (or some parts of it). In many scenarios, the key agreement and transport occur as exchange of control messages through a control channel. This channel does not interfere with the data channel in where actual secure data exchange takes place. A public-key cryptosystem (PKC) is commonly used in such setups in order to securely exchange through the control channel the symmetric-key cryptosystem (SKC) encryption/decryption keys used to securelyexchange data within the data channel. The latter keys are often called ephemeral or session keys, since their lifetime spans a specific time period i.e., a session and then they are disposed.In typical resource-limited environment, like the embedded systems are, it is rather costly to implement and use a publickey cryptography (PKC) scheme for secure communication between two entities. When the resource constraints are more severe or the participants are all known beforehand, another option is to replace the ―heavy‖ PKC scheme in the control channel with a lighter SKC scheme. The SKC scheme can use a master key in order to set and transfer the ephemeral keys needed for the data channel. In these cases and for sake of resource economy, the same SKC algorithm can be used in both the ―control‖ and ―data‖ channels albeit with different keys.An embedded system can incur an interesting tradeoff on security level and resource consumption. From a security point of view, the keys must be often refreshed, as explained earlier, in order to maintain the required security level. From a system resource consumption point of view, the keys must be rarely changed, in order to minimize the consumption of precious resources (processor, power, bandwidth). Further, in some usage scenarios, advanced care must be taken in order to ensure that the new keys will be available by the time they must be used, especially when only intermittent connectivity exists.The ―controlled randomness protocol‖ (CRP) for cryptographic key management was proposed as an improvement for the security level of secure communication protocols [2]. The CRP allows multiple keys to be valid at any given time; it neither alters the total number of keys needed in the underlying cryptographic algorithms, nor the need of a control channel to periodically refresh keys. However, the increased security offered by CRP allows for far less frequent key exchanges. The Microsoft .NET Compact Framework (.NET CF) is a software framework designed to run on mobile and embedded devices that are based on the Microsoft Windows CE platform. Example devices include smartphones, PDAs, and factory controllers. The .NET CF uses a subset of the libraries available in the full .NET Framework. It also includes some additional, mobile device-specific libraries. The .NET CF libraries are in fact stripped-down versions of the full .NET Framework libraries as to minimize their footprint and fit in the resourcelimited environment of the mobile and embedded devices.In this paper we assess the performance of the Controlled RandomnessProtocol when implemented on embedded systems running .NET CF. We present our findings from two different embedded platforms: one smartphone running Microsoft Windows Mobile 6.5 with .NET CF 3.5 and one smartphone running Microsoft Windows Phone 7 with .NET CF 4.0. We also verify our findings on acommodity desktop computer that supports the full .NET Framework 3.5. The performance reported in the latter environment is not consistent with our findings for the embedded platforms. We provide insights and possible explanations.The rest of the paper is organized as follows. Section II presents the key management problem and the controlled randomness protocol. Section III presents our testbed environment and experiments held. Section IV presents the results of our experiments and discusses our findings. Finally, Section V concludes our findings and discusses future directions of the work.II. THE CONTROLLED RANDOMNESS PROTOCOLConventional cryptographic schemes operate under the assumption that at most one key is active in any time moment. There is only one exception to this assumption. This is the the transition periods when changing a cryptographic key. In these cases, at most two keys can be active in order to cope with delayed messages. Two of the authors of this paper proposed a novel approach of having more than one key at any given time moment [2]. The approach is based on the concept of ―controlled randomness‖ i.e., rando mly using keys in a controlled environment. The concept of ―controlled randomness‖ can be utilized in any protocol that uses temporal (ephemeral) keys. It increases protocol security with minimal computational overhead. For sake of completeness, we describe in the following paragraphs the Controlled Randomness Protocol (CRP).A.Protocol DefinitionAssume a time period t = [0, T] composed of time slots t1, t2, . . . , tn such as t = t1 ∪ t2 ∪ . . . ∪ tn. Each time slot ti represents a session. Within each session one specific, temporal cryptographic key ki is used in conventional schemes. The Controlled Randomness Protocol works as follows. Within the time period t every cryptographic key k1, k2, . . . , kn is valid and can be used. The sender chooses with a uniform distribution a random integer i and encrypts the input data using the key ki. The receiver has access to a secret mechanism and upon receiving a ciphertext ci can deduce which of the possible keys was used for the encryptionand thus, use the correct one to decrypt the ciphertext. The CRP does not dictate how all these keys are transferred to the receiver. It can be through a control channel using a PKC scheme, or an SKC with master key, or any other method. The CRP dictates how all these keys are used and reused within a time frame composed of many conventional sessions.Two different methods are originally proposed in [2] for deriving the index, j, of the secret key used for a given ciphertext. The first method is using a synchronized randomnumber generator (RNG) in both the sender and the receiverfor the indexes.The second method involves usage of a Keyed Hash Function(KHF) also knownas Message Authentication Code(MAC). The sender and the receiver agree on a set of n encryption keys for a chosen encryption algorithm as usual and additionally on a set of n keys for computing MAC. The sender further uses an RNG. In this cases, the sender works as follows for every plaintext m:1) Sender chooses a random number j.2) Sender encrypts m under key kj to produce the ciphertext E(m, kj).3) Sender computes H(E(m, kj), hj) i.e., the MAC of the ciphertext using the j-th MAC key.4) Sender sends E(m, kj)||H(E(m, kj), hj), where || denotes the concatenation operation.The receiver works as follows to recover m from the quantity E(m, kj)||H(E(m, kj), hj):1) Receiver computes H(E(m, kj), hj) for every possible j = 1, 2, . . . , n. This step involves at most n MAC operations. Upon completing all computations, the receiver has derived the secret index j used by the sender.2) Receiver decrypts E(m, kj) using the j-th decryption key. This step involves one decryption operation and derives the plaintext m.B. Advantages of CRPThe concept of controlled randomness i.e., having multiple active keys at any given time moment, offers superior security characteristics compared to conventional protocols. The system designer can reuse well-known cryptographic blocks in an novel way to achieve increased security with minimal hassle:• minimal computational effort can be induced by CRP in the case that both sender and receiver can maintain a synchronized random number generator.• the synchronization requirement can be relaxed, if the system can sustain some increased computational effort induced by the KHF (MAC) operations.• in heavily constrained environments, the two above mechanisms can be replaced by sending the random number j with each packet. In this case, some security is indeed sacrificed since an attacker can know which packet is encrypted under what key. Yet, the intermix of keys allows consecutive packets to be encrypted under different keys and thus, protect against some cryptanalysis attacks.The CRP allows in all above scenarios to extend the lifetime of each key way beyond the time of a conventional session. Further, it allows less frequent exchanges of messages in the control channel (if one is implemented), since less keys are needed to achieve a specific security level for a specific timeframe. An attack on the classical key management protocol with a master key of n bits has complexity O(22n/3); an attack on the RNG for the controlled randomness protocol with _ keys has complexity O(l2m) (usually for m, the period of RNG, it holds m >> n); and an attack on the KHFmethod has a total complexity of O(l(2p + l2n/2)) where p the size in bits of the MAC keys [2].B.Problem statementIt is argued that the KHF (MAC) method leads to an efficient implementation in the case of combining a symmetric encryption algorithm with KHF operations, since the latter are an order of magnitude faster than the former [2]. This assumption holds if the MAC algorithm is implemented based on a hash algorithm rather than on a symmetric key algorithm. In the simplest scenario, a 0.05_ overhead is introduced on average for superior security. In a more complex scenario, this overhead can be lowered to 1%. This is achieved by performing the key detection function every few packets instead of each packet, as in the simpler scenario. We seek to validate these argument for overheads in the .NET Compact Framework 3.5 and 4.0. These frameworks are part of the operating system for modern smartphones and other embedded systems and are utilized for numerous applications and functionalities. III. METHODOLOGYA.Protocol implementation on .NET FrameworksWe implemented the classical protocols and the two methods of controlled randomness. The protocol implementation simulates a session of data where n keys are used in total for the three key management variants (classical, CRP with synchronized random number generation, and CRP with keyedhash function).We used as the underlying symmetric key encryption method the AES algorithm which is readily available in both Compact Frameworks (3.5 and 4.0). The .NET Compact Framework up to version 3.5 does not offer an implementation of a MAC algorithm. Thus, we implemented a MAC algorithmthat is based on the SHA1 hash function. The .NET CF 4.0 offers an HMAC implementation based on the SHA1 algorithm.For sake of completeness and comparison, we also implemented the three protocols in the .NET Framework 3.5 for a desktop computer.B.TestbedOur testbed consists of four platforms. The first one is the Windows Mobile emulator (Microsoft Visual Studio 2008 with Windows Mobile SDK). The emulator can emulate Windows Mobile 6.0 and 6.5 devices. The second one is a consumer device, an HTC Touch Pro smartphone. The smartphone runs a stock version of the operating system with .NET Compact Framework 3.5. The third one is the Windows Phone 7 emulator (Microsoft Visual Studio 2010 Express for Windows Phone with Windows Phone SDK). The emulator runs a stock version of the operating system with .NET Compact Framework 4.0.Finally, we used a PC running Microsoft Windows 7 with .NET Framework 3.5as a reference platform for validating our findings and checking for any differences between the .NET Framework and .NET Compact Framework implementations.C. ExperimentsWe run sets of experiments for release versions of the code, for Desktop, Windows Mobile 6.5 Professional (on emulator and real device), Windows Phone 7 (on emulator). In total, there are four (4) different setups to test. We did not carry real-world experiments for Windows Phone 7, due to lack of real devices by the time these experiments took place. We run two sets of experiments in all platforms. The first set relates to the performance of the CRP depending on the number of keys used.We run experiments for 4, 8, 16, and 32 keys. We opted to limit the experiments up to 32 keys since it already offers a superior level of security and keeps the average processing overhead relatively low.The second set relates to the performance of the CRP depending on input size. We run experiments for 32, 64, 128, and 256 KB. We opted not to validate for larger sizes given the constrained nature of the device. One should not realistically expect to exchange larger packets with such devices.IV. RESULTS AND DISCUSSIONAll measurements reported are the average time of 100 protocol executions for the .NET Compact Framework (3.5 and 4.0) and of 1,000 protocol executions for the .NET Framework 3.5. The mean times are in milliseconds. The execution time was measured using the System.TickCount API call, which offers millisecond granularity. The standard deviation was almost zero in all cases. This is an expected outcome, since the Windows Mobile operating system runs only one process each time. Thus, the execution path remains almost stable in all cases.A. Results for .NET Compact Framework 3.5We report in Table I the results for the .NET Compact Framework 3.5 on Windows Mobile 6.5. The experiments ran both on emulator and on a real device. No significant difference was observed in the two sets of measurements.A first finding is that the implementation of the AES algorithm in the .NET CF3.5 platform is extremely slow. This finding is consistent across all packet sizes and number of keys used. We also verified this in the initial benchmarks we ran for comparing AES with SHA1 implementation. Probably, AES implementation must be revised on this platform.The CRP/RNG implementation offers comparable performance with classical protocols for key management, although the latter do not utilize multiple keys per session. This is an expected behavior, since, from an implementation point of view, CRP/RNG adds only the use of a random numbergenerator.The CRP/HMAC implementation for the simple scenario (one HMAC per eachpacket) increases the required computational effort by a linear factor to both the packet size and the number of keys. The increase is between 10% (in case of 4 keys) and 80% (in case of 32 keys). When CRP/HMAC is implemented on the more complex scenario (one HMAC per n packets), the overheads are lowered, as expected, and within 1-20% range (n = 4 : 3.5 − 20%, n = 8 : 2 − 15%,and n = 16 : 0.7 − 7%).We note that it is up to the system designers to decide if, as the number of keys increases, this overhead is acceptable or to opt for fewer keys, without a big sacrifice in the achieved security level. The work for an eavesdropping attacker is smaller but remains exponential to both the symmetric key and the MAC key size, as described in Section II.B. Results for .NET Compact Framework 4.0We report in Table II the results for the .NET Compact Framework 4.0 on Windows Phone 7.0. The experiments ran on emulator only.The performance on the emulator for the .NET CF 4.0 is rather improved compared to that of .NET CF 3.5. All protocols now execute ten to twenty times faster. This improvement depends solely on the faster AES implementation. However, it is necessary to verify these findings on a real device, once it becomes available. It might be the case that the current version of the emulator contains an implementation of the algorithm that will not be incorporated in the final product.Initial benchmarking showed that the SHA-1 implementation on .NET CF 4.0 is slower than the SHA1 implementation on the .NET CF 3.5. The faster AES implementation combined with the slower HMAC algorithm results in larger overheads. This is because the performance of the two algorithms does not differ by an order of magnitude any more. We can now see overheads three to six times bigger than before on the same setup. As an example, consider the case of packet size of 64 KB with 32 keys: on .NET CF 3.5 we report a 64% overhead while on .NET CF 4.0 we report an overhead of 258.23%.As long as the results are further verified in a real device, the system designers should use the minimum acceptable number of keys as to minimize the induced computation overhead and retain a high level of security.C. Results for .NET Framework 3.5We report in Table III the results for the .NET Framework 3.5 on a desktop computer running Microsoft Windows 7 32- bit. Our findings on the desktop platform are quite similar with those reported in [3]. However, they are quite different on AES compared to the .NET CF 3.5. The performance deviation of AES in .NET CF 3.5 compared to .NET Framework 3.5 indicates that the two frameworks probably incorporate different implementations of the algorithm.The computational overhead for CRP/HMAC is increasing by a linear factor toboth the packet size and the number of keys. However, in absolute numbers, it remains within acceptable ranges. Thus, a system designer can opt for a larger number of keys as to achieve a very high level of security.V. CONCLUSIONS AND FUTURE WORKIn this paper we assessed the performance of the controlled randomness protocol when implemented in the .NET Compact Framework 3.5 and 4.0. Our findings validate the claims of the initial protocol proposal: the overhead on the encryption side is practically non-existent and only a small, tolerable processing overhead can be induced in the decryption side, despite the increased number of required computations. Thus, the controlled randomness protocol can be a viable implementation option in embedded systems equipped with the .NET Compact Framework for increasing the actual security of the underlying security protocol.A reference implementation on a commodity desktop revealed quite different performance figures for the two platforms (.NET Compact Framework 3.5 and .NET Framework 3.5). However, the desktop performance is in line with this published literature. It is an indication that the two platforms incorporate different implementations of cryptography, while sharing a large portion of other code and being akin.In the future, we would like to extend the work and compare with other cross-platform libraries, like a Java-based implementation. It is also interesting to validate our findings on the final version of Windows Phone 7 and on an actual device, once such a device is available. Another option is to extendour work on Google Android, Nokia Meemo, and possibly other similar devices. ACKNOWLEDGEMENTSDr. A.G. Voyiatzis and Prof. D.N. Serpanos were supported by the EU project INTERMEDIA (38419), in the frame of the EU IST FP6 Programme. REFERENCES[1] Jan C.A. Van Der Lubbe, Basic Methods of Cryptography. CambridgeUniversity Press, 1998.[2] D. N. Serpanos and A. G. Voyiatzis, ―Increasing symmetric k ey lifetime by controlled randomness,‖ in Emerging Technologies and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference on, vol. 2, Sept. 2005, pp. 575–580.[3] G. A. Francia and R. R. Francia, ―An Empirical Study on the Performance of Java/.NET Cryp tographic APIs,‖ Information Security Journal: A Global Perspective, vol. 16, no. 6, pp. 344–354, 2007.表格1：表格2：表格3：中文译文.NET Compact Framework嵌入式系统中的随机控制协议（CRP）性能摘要——用来进行密钥管理的随机控制协议（CRP）是提高安全通信协议的安全级别的一个方法。
论文中英文翻译(译文)
编号：桂林电子科技大学信息科技学院毕业设计(论文)外文翻译（译文）系别：电子工程系专业：电子信息工程学生姓名：韦骏学号：0852100329指导教师单位：桂林电子科技大学信息科技学院姓名：梁勇职称：讲师2012 年6 月5 日设计与实现基于Modbus 协议的嵌入式Linux 系统摘要：随着嵌入式计算机技术的飞速发展，新一代工业自动化数据采集和监测系统，采用核心的高性能嵌入式微处理器的，该系统很好地适应应用程序。
它符合消费等的严格要求的功能，如可靠性，成本，尺寸和功耗等。
在工业自动化应用系统，Modbus 通信协议的工业标准，广泛应用于大规模的工业设备系统，包括DCS，可编程控制器，RTU 及智能仪表等。
为了达到嵌入式数据监测的工业自动化应用软件的需求，本文设计了嵌入式数据采集监测平台下基于Modbus 协议的Linux 环境采集系统。
串行端口的Modbus 协议是实现主/从式，其中包括两种通信模式：ASCII 和RTU。
因此，各种药膏协议的设备能够满足串行的Modbus通信。
在Modbus 协议的嵌入式平台实现稳定和可靠。
它在嵌入式数据监测自动化应用系统的新收购的前景良好。
关键词：嵌入式系统，嵌入式Linux，Modbus 协议，数据采集，监测和控制。
1、绪论Modbus 是一种通讯协议，是一种由莫迪康公司推广。
它广泛应用于工业自动化，已成为实际的工业标准。
该控制装置或不同厂家的测量仪器可以链接到一个行业监控网络使用Modbus 协议。
Modbus 通信协议可以作为大量的工业设备的通讯标准，包括PLC，DCS 系统，RTU 的，聪明的智能仪表。
随着嵌入式计算机技术的飞速发展，嵌入式数据采集监测系统，使用了高性能的嵌入式微处理器为核心，是一个重要的发展方向。
在环境鉴于嵌入式Linux 的嵌入式工业自动化应用的数据，一个Modbus 主协议下的采集监测系统的设计和实现了这个文件。
因此，通信设备，各种药膏协议能够满足串行的Modbus。
嵌入式Linux概述中英文对照外文翻译文献
中英文资料对照外文翻译嵌入式Linux概述摘要本文我将论述一下嵌入式Linux目前的发展趋势（状况）。
我将概述Linux是什么，嵌入式Linux系统与桌面系统有什么不同的特点。
然后，我将详细地论述六个关键领域：•配置•实时性•图形用户界面•开发工具支持•经济性•技术支持选项下面，我将比较嵌入式Linux与Windows CE的实时性，操作系统映像大小和内存需求。
然后我会讨论一些基于嵌入式Linux的零售设备并与大家讨论一下关于嵌入式Linux一些大概的评论。
简介除非你在过去的几年里一直与世隔绝，否则毫无疑问你一定听说过Linux操作系统。
作为微软的Windows NT在软件开源中的竞争对手，它已经在软件开发和系统管理社区，以及主流的非技术性新闻媒体上被广泛宣传和激烈的讨论。
当Linux系统首次推出的时候，它是专门针对运行在英特尔80x86或兼容的微处理器上台式电脑。
引用Linux操作系统的创始Linus Torvalds说过的一句话：“ 从Linux操作系统诞生之日起，它将只会运行在拥有一块IDE硬盘的PC上” 。
回首至今为止的21世纪，这句话显得非常滑稽。
如今的Linux已经被移植到许多不同的微处理器上并运行在许多并不含有硬盘的平台上。
这些设备甚至没有通用的计算机系统，也没有如网络路由器，核心监控程序和用来跟踪旋风管的数据收集单位。
正是这些类型的系统，被统称为“嵌入式Linux” 。
在下一节我会关注嵌入式Linux系统和它的堂兄弟桌面Linux系统之间的区别。
然后，我要回详细描述嵌入式Linux在：配置，实时性， GUIs ，开发工具的支持，经济性，和技术支持这六个方面的特点。
然后，我将比较一下基于同样配置的嵌入式Linux内核与Windows CE内核的大小和实时性特征。
然后，我将讨论三个基于嵌入式Linux的有趣的设备：光学遥测系统，NetTel路由器和IBM公司的掌上电脑研究项目“ itsy ” 。
计算机英语2022影印版课后单词翻译解析
计算机英语2022影印版课后单词翻译解析计算机专业英语（2022影印版）高等教育出版社共10页KEYTERMS第一单元digitalveratiledic（DVD）数字多用途光盘digitalvideodic（DVD）数字多用途光盘documentfile文档文件enduer终端用户floppydik软盘informationytem信息系统informationtechnology信息技术inputdevice输入设备Internet因特网Keyboard键盘peronaldigitalaitant（PDA）个人数字助理preentationfile演示文稿primarytorage主存Printer打印机Procedure规程Program程序randomaccememory随机存储器econdarytoragedevice辅存Software 软件wirelerevolution无线革命workheetfile工作表第三单元analyticalgraph分析图计算机专业英语（2022影印版）高等教育出版社共10页applicationoftware应用软件AutocontentWizard内容提示向导baicapplication基础应用软件bulletedlit项目符号列表buineuite商业套装软件Button按键Cell单元格charactereffect字效Chart图表Column列databaemanagementytem(DBMS)数据库管理系统databaemanager数据库管理员Deigntemplate设计模板dialogbo某对话框Document文件Editing编辑Field字段findandreplace查找和替换Font字体fontize字号Form窗体Format格式Formula公式Function函数Gallerie图库grammarchecker语法检查器graphicaluerinterface(GUI)图形用户界面homeoftware家庭软件homeuite家庭套装软件Icon图标preentationgraphic图形演示文稿productivityuite生产力套装软件Query查询Range范围Recalculation重算Record记录relationaldatabae关系型数据Report报表Ribbon功能区、格式栏Row行Sheet工作表Slide幻灯片oftwareuite软件套装Sort排序pecializedapplication专用应用程序pecializeduite专用套装软件peechrecognition语音识别pellingchecker拼写检查器preadheet电子表格ytemoftware系统软件Table表格te某tentry文本输入Theauru[θi:r]分类词汇集计算机专业英语（2022影印版）高等教育出版社共10页Toolbar工具栏uerinterface用户界面utilityuite实用套装软件what-ifanalyi变化分析Window窗口wordproceor文字处理软件wordwrap字回行workbookfile工作簿Workheet工作表第四单元Animation动画artificialintelligence(AI)人工智能artificialreality虚拟现实audioeditingoftware音频编辑软件bitmapimage位图Blog博客Button按键clipart剪辑图Dektoppubliher桌面发布dektoppublihingprogram桌面印刷系统软件drawingprogram绘图程序e某pertytem专家系统Flah动画fuzzylogic模糊逻辑graphicalmap框图graphicuite集成图HTMLeditorHTML编辑器illutrationprogram绘图程序Imageeditor图像编辑器imagegallery图库immerivee某perience沉浸式体验indutrialrobot工业机器人Interactivity交互性knowledgebae知识库knowledge-baedytem知识库系统Link链接pagelayoutprogram页面布局程序perceptionytemrobot感知系统机器人Photoeditor图像编辑器Pi某el[pikl]像素raterimage光栅图像Robot机器人Robotic机器人学tockphotograph照片库toryboard故事版Vector[vekt]矢量vectorillutration矢量图vectorimage矢量图象videoeditingoftware视频编辑软件virtualenvironment虚拟环境virtualreality虚拟现实virtualrealitymodelinglanguage(VRML)虚拟现实建模语言virtualrealitywall虚拟现实墙VR虚拟现实Webauthoring网络编程Webauthoringprogram网络编辑程序Weblog网络日志计算机专业英语（2022影印版）高等教育出版社共10页Webpageeditor网页编辑器第五单元AddPrinterWizard添加打印机向导languagetranlator语言编译器leopard[lepd]雪豹操作系统Linu某MacOSMac操作系统MacOS某Menu菜单Antiviruprogram反病毒程序Backup备份backupprogram备份程序Booting启动、引导coldboot冷启动Dahboardwidget仪表盘Dektop桌面dektopoperatingytem桌面操作系统devicedriver磁盘驱动程序diagnoticprogram诊断程序dialogbo 某对话框DikCleanup磁盘清理DikDefragmenter磁盘碎片整理器Driver驱动器embeddedoperatingytem嵌入式操作系统File文件Folder文件夹Fragmented碎片化graphicaluerinterface(GUI)图形用户界面Help帮助Icon图标Multitaking多任务处理networkoperatingytem(NOS)网络操作系统networkerver网络服务器OneButtonCheckup一键修复operatingytem操作系统Platform平台Pointer指针Sector[ekt]扇区oftwareenvironment软件环境Spotlight聚光灯tand-aloneoperatingytem独立操作系统ytemoftware系统软件Tiger老虎操作系统Track磁道troublehootingprogram故障检修程序Unintallprogram卸载程序UNI某uerinterface用户界面Utility实用程序utilityuite实用套装软件Viru[vair]病毒warmboot热启动Window 视窗Window视窗操作系统WindowUpdateWindow更新计算机专业英语（2022影印版）高等教育出版社共10页WindowVitaWindow某P第六单元ACadapter交流适配器Acceleratedgraphicport(AGP):图形加速端口Arithmetic-logicunit（ALU）:算术逻辑单元Arithmeticoperation:算术运算ASCII美国标准信息交换码Binarycodingcheme:二进制编码制Bit:位Bu:总线Buline:总线Byte:字节Cable:电缆Cachememory:高速缓存carrierpackage封装物Centralproceingunit(CPU):中央处理器Chip:芯片Dektopytemunit:桌面系统单元Digital数字的Dual-corechip双核芯片EBCDIC:扩展二进制编码的十进制交换码E某panionbu扩展总线E某panioncard扩展卡E某panionlot扩展槽FireWireport:火线接口Flahmemory闪存Graphiccard图形适配卡Indutrytandardarchitecture（ISA）工业标准结构InfraredDataAociation（IrDA）红外线传输模组Muicalintrumentdigitalinterface（MIDI）乐器数字接口Networkadaptercard网络适配卡Networkinterfacecard（NIC）网络接口卡Notebookytemunit:笔记本Parallelport:并行端口Parallelproceing并行处理Pccard::个人计算机插卡PCIE某pre（PCIe）Peronaldigitalaitant(PDA)个人数字助理计算机专业英语（2022影印版）高等教育出版社共10页Plugandplay:即插即用Port:端口Powerupplyunit供电设备Proceor:处理器RAMcache:RAM高速缓存Random-accememory(RAM):随机存储器Read-onlymemory(ROM):只读存储器erialATA（SATA）串行ATA接口规范Serialport:串行端口Siliconchip:硅芯片Slot:插槽Smartcard:智能卡oundcard声卡Sytemboard:系统板Sytemcabinet:主机Sytemclock:系统时钟Sytemunit:系统单元tabletPC平板式电脑tabletPCytemunit平板式电脑系统单元TVtunercard:电视调频卡Unicode:统一字符编码标准Univeralerialbu(USB):通用串行总线Univeralerialbu(USB)port:通用串行总线端口Virtualmemory:虚拟存储器Word:字第七单元active-matri某monitor有源矩阵显示器barcode条形码barcodereader条形码阅读器cathoderaytubemonitor(CRT)阴极射线管显示器Clarity清晰度Digitalmediaplayer数字媒体播放器Digitalmuicplayer数码音乐播放器digitalvideocamera数码影像摄录机dotpitch点距dot-matri某printer针式打印机dot-per-inch(dpi)点每英寸dual-canmonitor双向扫描显示器dumbterminal哑终端e-book电子图书阅读器ergonomickeyboard人体工程学键盘Fa某machine传真机flat-panelmonitor平面显示器Flatbedcanner平板扫描仪fle某iblekeyboard可变形键盘handwritingrecognitionoftware手写识别软件Headphone耳机high-definitionteleviion(HDTV)高清电视计算机专业英语（2022影印版）高等教育出版社共10页laerprinter激光打印机lightpen光笔Liquidcrytaldiplay（LCD）液晶显示器Magneticcardreader磁卡阅读器magnetic-inkcharacterrecognition(MICR)磁性墨水字符识别mechanicalmoue机械鼠标Monitor显示器Moue鼠标mouepointer鼠标指针multifunctiondevice(MFD)多功能设备networkterminal网络终端numerickeypad数字小键盘optical-characterrecognition(OCR)光学字符识别optical-markrecognition(OMR)光学标记识别opticalmoue光电鼠标Opticalcanner光电扫描仪paive-matri某monitor无源矩阵显示器PDAkeyboardPDA键盘peronallaerprinter个人激光打印机photoprinter照片打印机pictureelement有效像素Pi某el像素Pi某elpitch像素间距platformcanner平版式扫描仪Plotter绘图仪pointingtick触控点portableprinter便携式打印机portablecanner便携式扫描仪Printer打印机Radiofrequencycardreader射频卡阅读器Radiofrequencyidentification（RFID）射频识别refrehrate刷新率Reolution分辨率rollerball 滚动球haredlaerprinter共享激光打印机Speaker扬声器Stylu[tail]输入笔thermalprinter[θ:ml]热敏打印机thinclient瘦客户端thinfilmtranitormonitor(TFT)薄膜晶体管显示器togglekey[tɡl]切换键touchpad触控板touchcreen触摸屏Trackball轨迹球traditionalkeyboard传统键盘UniveralProductCode(UPC)同一产品编码wandreader棒式阅读器WebCam摄像头计算机专业英语（2022影印版）高等教育出版社共10页wheelbutton滚动键wirelekeyboard无线键盘wirelemoue无线鼠标第八单元Cylinder[ilind]柱面Denity密度directacce直接存取dikcaching磁盘缓存DVD(digitalveratiledicordigitalvideodic)DVDplayerDVD播放器DVD-R(DVDrecordable)可录式DVDDVD+R(DVDrecordable)可录式DVDDVD-RAM(DVDrandom-accememory)DVD随机存取器DVD-ROM(DVDrandom-read-onlymemory)DVD只读存储器DVD-ROMjukebo某DVD-RW(DVDrewritable)可重写DVDEnterprietorageytem企业存储系统Floppydikcartridge软盘盒floppydikdrive(FDD)软磁盘驱动器harddik硬盘hard-dikcartridge硬盘盒hard-dikpack硬盘组HDDVD(high-definitionDVD)高清DVDopticaldikdrive光盘驱动器OrganizationalInternettorage组织性网络存储PCCardharddikPC卡硬盘Pit坑primarytorage主存RAIDytem磁碟阵列系统计算机专业英语（2022影印版）高等教育出版社共10页Redundantarrayofine某peniveclient/ervernetworkytem客户/服dik(RAID)廉价磁盘冗余阵列econdarytorage辅存Sector扇区equentialacce顺序存取Shutter滑盖Softwareengineer软件工程师olid-tatetorage固态存储器toragedevice存储装置tapecartridge盒式带Track轨道USBdriveUSB驱动器write-protectionnotch写入保护缺口第九单元3Gcellularnetworkanalogignal模拟信号aymmetricdigitalubcriber（ADSL）非对称数字用户线路Backbone 中枢Bandwidth带宽baetation基址bitperecond位/秒Bluetooth蓝牙Broadband宽带broadcatradio无线广播Bu总线bunetwork总线网络cablemodem电缆调制解调器cellularervice无线服务Client客户务网络系统digitalubcriberline(DSL)数字用户线路ditributeddataproceing分布式数据处理系统ditributedproceing分布处理domainnameerver(DNS)域名服务Ethernet以太网e某ternalmodem外置调制解调器E某tranet外联网fiber-opticcable光纤电缆Firewall防火墙globalpoitioningytem(GPS)全球卫星定位系统internalmodem内置式调制解调器Intranet内联网IPaddre(InternetProtocoladdre)IP地址localareanetwork(LAN)局域网lowbandwidth低频带宽计算机专业英语（2022影印版）高等教育出版社共10页mediumband中频波段metropolitanareanetwork(MAN)城域网Microwave微波Modem调制解调器Modulation调制networkadminitrator网络管理员networkarchitecture网络体系结构networkgateway网关networkhub网络集线器networkinterfacecard(NIC)网络接口卡networkoperatingytem(NOS)网络操作系统Node节点Packet数据包PCcardmodemPC卡调制解调器peer-to-peernetworkytem对等网络系统Polling轮流检测Protocol协议pro某yerver代理服务器ringnetwork环型网络Satellite卫星atellite/airconnectionervice卫星互连服务Server服务器(tranmiioncontrolprotocol/Internetprotocol)传输控制协议/因特网协议voiceband 声音带宽wideareanetwork(WAN)广域网Wi-FI(wirelefidelity)无限保真wireleLAN(WLAN)无线局域网wirelemodem无线调制解调器wirelereceiver无线接收器。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Web Server for Embedded SystemsAfter the “everybody-in-the-Internet-wave” now obviously follows the“everything-in-the-Internet-wave”.The most coffee, vending and washingmachines are still not available about the worldwide net. However the embeddedInternet integration for remote maintenance and diagnostic as well as the so-calledM2M communication is growing with a considerable speed rate.Just the remote maintenance and diagnostic of components and systems by Webbrowsers via the Internet, or a local Intranet has a very high weight for manydevelopment projects. In numerous development departments people work oncompletely Web based configurations and services for embedded systems. Theremaining days of the classic user interface made by a small LC-display with frontpanel and a few function keys are over. Through future evolutions in the field ofthe mobile Internet, Bluetooth-based PAN s (Personal Area Network's) andthe rapidly growing M2M communication (M2M=Machine-to-Machine)a further innovating advance is to be expected.The central function unit to get access on an embedded system via Web browser isthe Web server. Such Web servers bring the desired HTML pages (HTML=HyperText Markup Language) and pictures over the worldwide Internetor a local network to the Web browser. This happens HTTP-based (HyperText Transfer Protocol). A TCP/IP protocol stack –that means it is based onsophisticated and established standards–manages the entire communication.Web server (HTTP server) and browser (HTTP client) build TCP/IP-applications. HTTP achieved a phenomenal distribution in the last years.Meanwhile millions of user around the world surf HTTP-based in the WorldWide Web. Today almost every personal computer offers the necessaryassistance for this protocol. This status is valid more and more for embeddedsystems also. The HTTP spreads up with a fast rate too.1. TCP/IP-based HTTP as Communication PlatformHTTP is a simple protocol that is based on a TCP/IP protocol stack (picture 1.A).HTTP uses TCP (Transmission Control Protocol). TCP is a relative complex andhigh-quality protocol to transfer data by the subordinate IP protocol. TCP itselfalways guarantees a safeguarded connection between two communication partnersbased on an extensive three-way-handshake procedure. As aresult the data transfer via HTTP is always protected. Due tothe extensive TCP protocol mechanisms HTTP offers only a low-gradeperformance.Figure 1: TCP/IP stack and HTTP programming modelHTTP is based on a simple client/server-concept. HTTP server and clientcommunicate via a TCP connection. As default TCP port value the port number80 will be used. The server works completely passive. He waits for a request(order) of a client. This request normally refers to the transmition of specificHTML documents. This HTML documents possibly have to be generateddynamically by CGI. As result of the requests, the server will answer with aresponse that usually contains the desired HTML documents among others(picture 1.B).GET /test.htm HTTP/1.1Accept]: image/gif, image/jpeg, */*User selling agent: Mozilla/4.0Host: 192.168.0.1Listing 1.A: HTTP GET-requestHTTP/1.1 200 OKDate: Mon, 06 Dec 1999 20:55:12 GMTServer: Apache/1.3.6 (Linux)Content-length: 82Content-type: text/html<html><head><title>Test-Seite</title></head><body>Test-SeiteThe DIL/NetPCs DNP/1110 – Using the Embedded Linux</body></html>Listing 1.B: HTTP response as result of the GET-request from listing 1.AHTTP requests normally consist of several text lines, which are transmitted to theserver by TCP. The listing 1.A shows an example. The first line characterizes therequest type (GET), the requested object (/test1.htm) and the used HTTP version(HTTP/1.1). In the second request line the client tells the server, which kind offiles it is able to evaluate. The third line includes information about theclient- software. The fourth and last line of the request from listing 1.A is used toinform the server about the IP address of the client. In according to the type ofrequest and the used client software there could follow some further lines. Asan end of the request a blank line is expected.The HTTP responses as request answer mostly consist of two parts. At first thereis a header of individual lines of text. Then follows a content object (optional).This content object maybe consists of some text lines –in case of a HTML file– ora binary file when a GIF or JPEG image should be transferred. The first line of theheader is especially important. It works as status or error message. If anerror occurs, only the header or a part of it will be transmitted as answer.2. Functional principle of a Web ServerSimplified a Web server can be imagined like a special kind of a file server.Picture 2.A shows an overview. The Web server receives a HTTP GET-requestfrom the Web browser. By this request, a specific file is required as answer (seestep 1 into picture 2.A). After that, the Web server tries to get access on the filesystem of the requested computer. Then it attempts to find the desired file (step 2).After the successful search the Web server read the entire file(step 3) and transmit it as an answer (HTTP response comprising of headerand content object) to the Web browser (step 4). If the Web server cannot findthe appropriate file in the file system, an error message (HTTP response whichonly contains the header) is simply be send as response to the client.Figure 2: Functional principle from Web server and browserThe web content is build by individual files. The base is build by static files withHTML pages. Within such HTML files there are references to further filesembedded –these files are typically pictures in GIF or JPEG format. However,also references to other objects, for example Java-Applets, are possible. After aWeb browser has received a HTML file of a Web server, this file will beevaluated and then searched for external references. Now the steps 1 to 4 frompicture 2.A will run again for every external reference in order to request therespective file from the corresponding Web server. Please note, that such areference consists of the name or IP address of a Web server (e.g. ""),as well as the name of the desired file (e.g. "picture1.gif"). So virtually everyreference can refer to another Web server. In other words, a HTML file could belocated on the server "ssv-embedded.de" but the required picture -which isexternal referenced by this HTML file- is located on the Web server"". Finally this (worldwide) networking of separate objects is thecause for the name World Wide Web (WWW). All files, which are required by aWeb server, are requested from a browser like the procedure shown on picture2.A. Normally these files are stored in the file system of the server. TheWebmaster has to update these files from time to time.A further elementary functionality of a Web server is the CommonGateway Interface(CGI) -we have mentioned before. Originally this technologyis made only for simple forms, which are embedded into HTML pages. The data,resulting from the padding of a form, will be transmitted to a Web server viaHTTP-GET or POST-request (see step 1 into picture 2.B). In such a GET- orPOST-request the name of the CGI program, which is needed for theevaluation of a form, is fundamentally included. This program has to be on theWeb server. Normally the directory "/cgi-bin" is used as storage location.As result of the GET- or POST-request the Web server starts the CGI programlocated in the subdirectory "/cgi-bin" and delivers the received data in form ofparameters (step 2). The outputs of a CGI program are guided to the Web server(step 3). Then the Web server sends them all as responses to the Web browser(step 4).3. Dynamic generated HTML PagesIn contradiction to a company Web site server, which informs people about theproduct program and services by static pages and pictures, an embeddedWeb server has to supply dynamically generated contents. The embedded Webserver will generate the dynamic pages in the moment of the first access by abrowser. How else could we check the actual temperature of a system viaInternet? Static HTML files are not interesting for an embedded Web server.The most information about the firmware version and service instructions arestored in HTML format. All other tasks are normally made via dynamic generatedHTML.There are two different technologies to generate a specific HTML page in themoment of the request: First the so-called server-side-scripting and secondthe CGI programming. At the server-side-scripting, script code is embeddedinto a HTML page. If required, this code will be carried out on the server (server-sided).For this, there are numerous script languages available. All these languages areusable inside a HTML-page. In the Linux community PHP is used mostly. Thefavourite of Microsoft is VBScript. It is also possible to insert Java directly intoHTML pages. Sun has named this technology JSP(Java Server Pages).The HTML page with the script code is statically stored in the file system of theWeb server. Before this server file is delivered to the client, a special programreplaces the entire script code with dynamic generated standard HTML. The Webbrowser will not see anything from the script language.Figure 3: Single steps of the Server-Side-ScriptingPicture 3 shows the single steps of the server-side-scripting. In step 1 the Webbrowser requests a specific HTML file via HTTP GET-request. The Web serverrecognizes the specific extension of the desired file (for example *.ASP or *.PHPinstead of *.HTM and/or *.HTML) and starts a so-called scripting engine(see step 2). This program gets the desired HTML file including the script codefrom the file system (step 3), carry out the script code and make a newHTML file without script code (step 4). The included script code will be replacedby dynamic generated HTML. This new HTML file will be read by the Webserver (step 5) and send to the Web browser (step 6). If a server-sided scripting issupposed to be used by an embedded Web server, so you haveto consider the necessary additional resources. A simple example: In orderto carry out the embedded PHP code into a HTML page, additional programmodules are necessary for the server. A scripting engine together with theembedded Web server has to be stored in the Flash memory chip of an embeddedsystem. Through that, during run time more main memory is required.4. Web Server running under LinuxOnce spoken about Web servers in connection with Linux most peopleimmediately think of Apache. After investigations of the Netcraft Surveythis program is the mostly used Web server worldwide. Apache is anenhancement of the legendary NCSA server. The name Apache itself hasnothing to do with Red Indians. It is a construct from "A Patchy Server" becausethe first version was put together from different code and patch files.Moreover there are numerous other Web servers - even for Linux. Most of this arestanding under the GPL (like Apache) and can be used license free. Avery extensive overview you can find at "/". EveryWeb server has his advantages and disadvantages. Some are developed forspecific functions and have very special qualities. Other distinguishes at bestthrough their reaction rate at many simultaneous requests, as wellas the variety of theirconfiguration settings. Others are designed to need minimal resources and offer very small setting possibilities, as well as only one connection to a client.The most important thing by an embedded Web server is the actual resource requirements. Sometimes embedded systems offer only minimal resources, which mostly has to be shared with Linux. Meanwhile there are numerous high- performance 32-bit-386/486-microcontroller or (Strong)ARM-based embedded systems that own just 8 Mbytes RAM and 2 Mbytes Flash-ROM (picture 4). Outgoing from this ROM (Read-only-Memory, i.e. Flash memory chips) a complete Linux, based on a 2.2- or 2.4-Kernel with TCP/IP protocol stack and Web server, will be booted. HTML pages and programs are also stored in the ROM to generate the dynamic Web pages. The space requirements of an embedded system are similar to a little bigger stamp. There it is quite understandable that there is no place for a powerful Web server like Apache.Figure 4: Embedded Web Server Module with StrongARM and LinuxBut also the capability of an Apache is not needed to visualize the counter of a photocopier or the status of a percolator by Web servers and browsers. In most cases a single Web server is quite enough. Two of such representatives are boa () and thttpd (). At first, both Web servers are used in connection with embedded systems running under Linux. The configuration settings for boa and thttpd are poor, but quite enough. By the way, the source code is available to the customer. The practicable binary files for these servers are always smaller than 80 Kbytes and can be integrated in the most embedded systems without problems. For the dynamic generation of HTML pages both servers only offer CGI (Common Gateway Interface) as enlargement. Further technologies, like server-side-includes (SSI) are not available.The great difference between an embedded Web server and Apache is, next to the limited configuration settings, the maximal possible number of simultaneous requests. High performance servers like Apache immediately make an own process for every incoming call request of a client. Inside of this process allfurther steps will then be executed. This requires a very good programming and a lot of free memory resources during run time. But, on the other hand many Web browsers can access such a Web server simultaneously. Embedded Web server like boa and thttpd work only with one single process. If two users need to get access onto a embedded Web server simultaneously, one of both have to wait a few fractions of a second. But in the environment of the embedded systems that is absolutely justifiable. In this case it is first of all a question of remote maintenance, remote configuration and similar tasks. There are not many simultaneous requests expected.The DIL/NetPCs DNP/1110 – Using the Embedded LinuxList of FiguresFigure 1: TCP/IP stack and HTTP programming modelFigure 2: Functional principle from Web server and browserFigure 3: Single steps of the Server-Side-ScriptingFigure 4: Embedded Web Server Module with StrongARM and LinuxListingsListing 1.A: HTTP GET-requestListing 1.B: HTTP response as result of the GET-request from listing 1.A ContactSSV Embedded SystemsHeisterbergallee 72D-30453 HannoverTel. +49-(0)511-40000-0Fax. +49-(0)511-40000-40Email: sales@ist1.deWeb: www.ssv-embedded.deDocument History (Sadnp05.Doc)Revision Date Name1.00 24.05.2002FirstVersion KDWThis document is meant only for the internal application. The contents ofthis document can change any time without announcement. There is takenover no guarantee for the accuracy of the statements. Copyright ©SSV EMBEDDED SYSTEMS 2002. All rights reserved.INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'ASIS' WITHOUT WARRANTY OF ANY KIND. The user assumes the entirerisk as to the accuracy and the use of this document. Some names withinthis document can be trademarks of their respective holders.嵌入式系统的网络服务器在“每个人都处在互联网的浪潮中”之后，现在很明显随之而来的是“每件事都处在互联网的浪潮中”。