a Universal Development Environment for Formal Methods

B1U6-U8课后段落翻译中英对照版B1 U6Part IGap year（间隔年）refers to a period of time---not necessarily a year--- in which students take timeoff and do something other than schooling, such as travel or work. The year out is most commonlytaken after high school and before going to university. During this time, a student might travel,engage in volunteer work or undertake （承担）a working holiday abroad.A new trend is toparticipate in international education programs that combine language study, home stays, culturalexchange, community service, and independent study. The practice of taking a year out developedin the United Kingdom in the 1960s. It has grown very popular among students in the UK, Australia, New Zealand, and Canada. In the United States however, the practice of taking a year off remains the exception （例外）. But in recent years, taking a year out has become slightly more common for Americans. Some 40,000 American students participated in 2013 in gap year programs, an increase of almost 20% since 2006. Universities such as Princeton University, Harvard University,Massachusetts Institute of Technology have formal policies allowing students to defer （延期）admission.间隔年指的是学生休假不去上学而去旅游或工作等的一段时间，但不一定是一年。

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

RTD (Rapid Test Designer)LTE Protocol Development ApplicationMX786201AIntroductionThe RTD is a unique environment for creating test scenarios to prove the protocol & behavior of modern wireless terminals. The Graphical Flow Chart brings many benefits to test creators as well as those executing the tests and provides fast flexible methods for test iteration, as well as creation and maintenance.The RTD comes with a suite of multi-RAT (GERAN/UTRAN/LTE) signaling testing libraries for creating and executing tests on the industry standard MD8480C (GERAN/UTRAN) and MD8430A (LTE) signalling tester platforms. Together they provide terminal development organizations with the tools needed to support their development cycle, through integration and onto inter-operability, regression and acceptance. Additionally the MD8470A provides a system for LTE/CDMA 2000 inter-working development.Detailed test annotation and test flowThe graphical layout of each test makes it straightforward to visualize the test flow and hence verify and debug the terminal’s behavior. Tests can be annotated, enabling easy identification of logical and functional blocks so that they may be re-used by “cutting and pasting” into a new test if required. Test flow is available when manually investigating failures or when checking for specific conditions.•Fast test creation and execution – tests can be easily created and modified for fast debug and analysis•Built in pass/fail judgment - preliminary judgment of the tests results using criteria simplifies analysis •Automation of tests – built in intelligent test sequencer and control of device under test means campaigns can be run unattended•Real time displays – Many parameters are shown during test execution for performance analysis •Proven hardware reliability – existing MD8480C users will know the benefits from the most stable platform – MD8430A extends that reliabilityVirtual Front panelThe RTD allows terminal development teams to create test scenarios with virtual front panel control. This provides a fast development, debug and proving environment without the need to recompile between iterations. In some cases it is possible to make changes to the parameterization while tests are running for examination of performance Automating the scenarios is also possible, so a single test can be used to check over a range of values without any human intervention. A real time measurement and monitoring application is available to see the effect of different loading and scheduling.Virtual ButtonsTests can include “soft-buttons” that allow a variety of functions and features for manual investigation of terminal performance. E.g. control of power levels during tests to be modified without re-running the tests.Example of virtual front panel with soft keysProcedure Library supportThere are two RTD Procedure Libraries available. LTE Low-level Configuration Library (Mar09) and a UTRAN/GERAN Layer 3 Procedure Library.These libraries are maintained with the 3GPP protocol specifications to provide a system that not only stays up to date with latest changes in the 3GPP process but also allows the user to upgrade existing test scenarios with a single command.LTE Procedure LibrariesAs LTE matures, the number of procedural blocks will increase and with updates occurring every 3 months, users can expect to keep up with 3GPP developments.UTRAN/GERAN Procedure Libraries3GPP progressionA very important feature of the RTD is the ability to update tests to the latest 3GPP Release. Entire archives of test scenarios can be updated automatically and for regression, backups of the original are saved.The Measurement and Monitor ApplicationRuntime information is available to the user in a number of ways. As well as protocol messages, the RTD provides an application that is used to measure throughput under a number of scenarios.Conditions can be changed while displaying the throughput of data in the graphical window.The Dynamic MSC provides a message sequence chart as the test progresses. This information is dynamically updated during runtime. The user can switch between Diagram and MSC view while the test is running without interrupting the logging of trace information. The trace is cleared when the test is rerun, but all the information from the test run will be stored in a Test Log Results file ready to view with the Protocol Analyzer.Test Results AnalysisThe RTD provides several ways to observe test results. A complete log of the messages is captured for viewing with the in-built protocol analyzer or may be exported to HTML for viewing on a web browser. Criteria EditorThe RTD is able to provide a preliminary judgment of the tests results using criteria that can be set by the test creator or modified later for custom judgment of the results. The criteria are determined by the flow of the tests with multiple loops possible to ensure that behavior is accurately recorded. At a high level: this is shown by a simple pass or fail .Further investigation reveals the cause of failure or abnormality.The screen below shows the criteria applied to the example test to determine incorrect behavior that can be traced back to the protocol messages in the resultant log.The test criteria may be modified by the user to prove specific functionality and applied to new and existing tests. For existing tests it has the added benefit that tests do not need to be re-run to analyze results against new criteria. Watermarking of tests and resultsWe encourage users to make copies of the tests and make changes for debug and other purpose, so all tests in the Anritsu test packages have a watermark that is broken if the test is modified. This provides confidence to the user that the tests and results from original tests have not been modified.SHOWS THE TEST AND RESULTS ARE WATERMARKEDWATERMARK BROKENAutomating testsRunning the Test Cases Using the AT/MMI Proxy for AutomationThe RTD provides proxy control of the AT command set to the terminal through the RTD Test Cases. It enables automated testing to be achieved through a serial porton the control PC. In order to use the AT commandsprovided within the test cases, the RTD AT/MMIcommand interface must be set to use the appropriateserial port connection and an appropriate proxy.xml file is applied to map the AT/MMI commands to matchthose supported by the terminal.Prompts on the screen can be suppressed whenautomation is used.Some points to note:•In general automated testing can be carried out via the use of the AT command set[3GPP TS27.007] •Full control of a terminal is only possible if the terminal vendor has made provision for anautomated testing interface•The combined AT/MMI proxy was developed as a flexible interface which can adapt to manydifferent types of terminals through the use of aconfiguration file ‘proxy.xml’•Where the vendor has not implemented a given AT command, for instance AT+CFUN which is used to power cycle the terminal between tests, itmay be possible to use the Keypad Controlcommand (AT+CKPD) which simulates the pressing of the terminal key pad via the AT commandinterface.Running the RTD within a test systemThe RTD may also be controlled using remote commands and integrated into a total test system. The RTD is compatible with a number of remote commands that allow Tests to be RUN, ANALYZED, etc.Campaign management within the tool The RTD includes campaign management. This provides the user with the ability to create test runs that can be run remotely.Tests can be repeated depending on rules set by the user. Results are generated in a tabular form and can be exported to form part of a formal report.A campaign may be used to run an entire suite of conformance tests, or inter-operability tests, or any other large grouping of tests.Test ResultsTest results may be summarized for reports and exported to external formats (such as XML or CSV). The Results Overview created within the tool may be used for regression purposes.LTE / UTRAN / GERAN Inter-workingThe RTD is able to control the MD8430A and MD8480C to simulate network behavior in LTE / UTRAN / GERAN Inter-working processes. This provides a compelling way for existing RTD users to upgrade using their existing tests and experience to develop even greater test coverage.LTE, UTRAN, and GERAN procedures can be used in a single test to create a combinedLTE/UTRAN/GERAN test.•MD8480C specifications•Up to 4 W-CDMA* cells and 2 TDMA** cells •Up to 2 physical RF channels•HSDPA up to 14.4MB: HSUPA up to 5.7MB •Enhancement to HSPA Evo•Part of RTD, PTS and PCT systems •MD8430A specifications•LTE for FDD and TDD covering 350 to 3000 MHz frequency band•100 MB (DL): 50 MB (UL)• 4 RF supports 2x2MIMO handover •Up to 6 Cells (2 communication, 4 neighbor)•Future proof – Cat 4 todayLTE/UTRAN/GERANterminalUTRAN/GERAN Simulation(3GPP Release 6 or before) MD8430AMD8480CRTDRTDCombinedLTE/UTRAN/GERANTestRTD Test PackagesIn order to provide the fastest route to market, RTD has an LTE Integration library available as an option for LTE development teams. The tests provide developers and integrators with 29 tests that will be available through 2010 and 2011.•Each test case is specified with a test case title, a brief description of the aim of the test case and the SS feature that they intend to demonstrate•The test cases are chosen to cover the majority of the LTE/SAE protocol areas•The test cases are designed to be usable as full-stack building blocks for customers to use to build system testsSupport and maintenance of the test packages includes upgrading and re-validating existing test cases to new platform versions of RTD as well as later 3GPP releases.We have support staff in the USA, UK and Japan to provide support to customers on issues they may have with their devices using tests in the test packages.Reference Test packagesRTD is delivered withreference test packages thatprovide a natural way todiscover the features andbenefits of the RTD. Coupledwith the operation manualsand the on-line help, thesetests are part of the overalltraining program.Acceptance Test packagesThere are a number of acceptance test packages available for RTD including The AT&T IOT Library Packages and T-Mobile USA UMTS Protocol Test Library PackagesRTD users now have the ability to purchase the Libraries outright or subscribe to them on an annual basis to suit their fiscal needs.Other 3rd party library packages may be available through partnerships with network operators.Watermarking of tests and resultsWe encourage users to make copies of the tests and make changes for debug and other purpose, so all tests in the Library have a watermark that is broken if the test is modified. This provides confidence to the user that the tests and results from original tests have not been modified.SHOWS THE TEST AND RESULTSARE WATERMARKEDWATERMARK BROKENOrdering informationRTD is configured to be very flexible and to allow existing Anritsu products to be updated and upgraded while still protecting investment in tests and equipment. Two examples of typical systems is shown below.LTE Protocol development systemConfigured for LTE R&D, Integration and regression with multi-cell capability L1/L2 and L3 Libraries & LTE Integration Test Package – uses MD8430A – STM hardware.ApplicationsThis configuration provides L1 / L2 and a L3 capability to allow LTE multi-cell test creation, editing and executing of the testsTechnologyThis configuration is for LTE FDDToolsThis configuration has full automation of tests and control of the DUT.ServicesSupport and maintenance for RTD is on an annual basis.Test PackagesThere are test packages for a number of different applications and technologies. This configuration provides an LTE package MX786201A – Rapid Test Designer (RTD) chassisMX786201A-028 – Layer 1 / 2 Statistics monitorMX786201A-038 - Low-level Configuration Library (LTE) MX786201A-039 - Layer 3 Procedure Library (LTE)MX786201A-040 – RTD CipheringMX786201A-045 - RTD test creation and editing capability MX786201A-052 – RTD dual-cell capability (run-time option) MX786201A-020 – Annual software support and maintenanceMX787201A - Framework chassisMX787201A-027 - Framework LTE coreMX787201A-028 - Framework LTE FDD option'MX787201A-SS100 – Annual support and maintenanceMX787401A - Signaling application tools chassisMX787401A-011 - Protocol Analyzer(RTD)MX787401A-012 - Remote controlMX787401A-013 - Terminal controlMX787401A-014 - Signaling Application Tool for TestSequencingMX787401A-SS100 – Annual support and maintenanceMX786201A-024 RTD Advanced Training Course (5 days)MX786201A-911 – LTE Integration Test Package for RTD NOTE: Blue text denotes optionalOther options to consider:MX786201A-026 - Framework HSPA Evo (R8)MX786201A-029 - Framework LTE TDDMX786201A-031 - Framework CDMA 2000 (C2k)MX786201A-041 - Layer 3 Procedure Library (UTRAN/GERAN)MX786201A-047 - 3 x RTD creation and editing licencesMX787201A-012 - Multiple h/w platform support RTD (MD8480/8430/8470)MX787201A-021 - Framework GERAN coreMX787201A-023 - Framework UTRAN core (Rel-99 to Rel-7 inclusive)MX787201A-046 - RTD Multi cell capability (run-time option) [alternative to MX787201A-052] MX787201A-051 - Floating (server based) licenseMX787401A-061 - Interface driver for MD1230A/B (data analyzer)MX787401A-062 - Interface driver for MF6900A (fading simulator)LTE / UTRAN / GERAN Protocol development systemConfigured for LTE / UTRAN / GERAN R&D, Integration and regression with multi-cell capability L1/L2 and L3 Libraries & LTE Integration Test Package – usesMD8430A – STM and MD8480C hardware.ApplicationsThis configuration provides L1 / L2 and a L3 capability to allow LTE multi-cell test creation, editing and executing of the testsTechnologyThis configuration is for LTE FDDToolsThis configuration has full automation of tests and control of the DUT.ServicesSupport and maintenance for RTD is on an annual basis.Test PackagesThere are test packages for a number of different applications and technologies. This configuration provides an LTE package MX786201A – Rapid Test Designer (RTD) chassisMX786201A-028 – Layer 1 / 2 Statistics monitorMX786201A-038 - Low-level Configuration Library (LTE) MX786201A-039 - Layer 3 Procedure Library (LTE)MX786201A-040 – RTD CipheringMX786201A-045 - RTD test creation and editing capability MX786201A-046 - Multi-cell capability (run-time option)MX786201A-020 – Annual software support andmaintenanceMX787201A - Framework chassisMX787201A-012 - Multiple h/w platform support RTD(MD8480/8430/8470)MX787201A-021 - Framework GERAN coreMX787201A-023 - Framework UTRAN core (Rel-99 to Rel-7inclusive)MX786201A-026 - Framework HSPA Evo (R8)MX787201A-027 - Framework LTE coreMX787201A-028 - Framework LTE FDD optionMX786201A-041 - Layer 3 Procedure Library(UTRAN/GERAN)'MX787201A-SS100 – Annual support and maintenance MX787401A - Signaling application tools chassisMX787401A-011 - Protocol AnalyzerMX787401A-012 - Remote controlMX787401A-013 - Terminal controlMX787401A-014 - Signaling Application Tool for TestSequencingMX787401A-SS100 – Annual support and maintenanceMX786201A-024 RTD Advanced Training Course (5 days) MX786201A-911 – LTE Integration Test Package for RTD NOTE: Blue text denotes optionalOther options to consider:MX786201A-029 - Framework LTE TDDMX786201A-031 - Framework CDMA 2000 (C2k)MX786201A-047 - 3 x RTD creation and editing licencesMX787201A-051 - Floating (server based) licenseMX787401A-061 - Interface driver for MD1230A/B (data analyzer)MX787401A-062 - Interface driver for MF6900A (fading simulator)RTD is also available for terminal acceptance and interoperability. Please see the appropriate data sheet for a full description and list of Options and Support details.。

发展作文英语怎么说下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copyexcerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!Development is crucial for any society to thrive. It brings progress, innovation, and improvement. It is the driving force behind advancements in technology, infrastructure, and economy. Without development, a society would stagnate and fall behind. Development is not just about economic growth; it also encompasses social, cultural, and environmental aspects. It is a multifaceted processthat requires continuous effort and adaptation.In today's fast-paced world, development is happeningat an unprecedented rate. New technologies are emerging, industries are evolving, and lifestyles are changing. This rapid development brings both opportunities and challenges. On one hand, it creates jobs, improves living standards,and enhances connectivity. On the other hand, it can leadto inequality, environmental degradation, and cultural homogenization. Therefore, it is important to ensure that development is sustainable, inclusive, and equitable.Education plays a crucial role in driving development.It empowers individuals, equips them with knowledge and skills, and enables them to contribute to society.Education is not just limited to formal schooling; it can happen in various forms and settings. It is a lifelong process that should be accessible to all, regardless of age, gender, or background. By investing in education, we invest in the future of our society.Infrastructure development is another key aspect of overall development. Good infrastructure facilitates economic activities, improves connectivity, and enhancesthe quality of life. It includes transportation systems, energy networks, communication facilities, and public amenities. By investing in infrastructure, we create asolid foundation for further development and attract investments.Innovation and entrepreneurship are essential for sustainable development. They drive economic growth, create jobs, and foster creativity. Innovation can come in various forms, from technological breakthroughs to new businessmodels. It encourages experimentation, risk-taking, and problem-solving. By fostering a culture of innovation and supporting entrepreneurs, we can unleash the potential for growth and development.Environmental sustainability is a crucial consideration in any development process. As we strive for progress, we must also protect our natural resources and preserve the environment for future generations. Sustainable development aims to meet the needs of the present without compromising the ability of future generations to meet their own needs. It requires us to adopt environmentally friendly practices, reduce waste and pollution, and promote renewable energy sources.In conclusion, development is a complex and ongoing process that encompasses various aspects of society. It requires continuous effort, adaptation, and innovation. Education, infrastructure, innovation, and environmental sustainability are all key components of development. By striving for sustainable and inclusive development, we can create a better future for all.。

唱歌对教育意义英语作文下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copyexcerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!Singing has always been an integral part of human culture. It has a profound impact on education, both in formal settings like schools and universities, as well as in informal contexts. Singing helps to foster creativity, improve language skills, and enhance social interaction.When students engage in singing, they are encouraged to think creatively and express themselves in a unique way. Singing allows them to explore different melodies, rhythms, and harmonies, enabling them to develop their own musical style. This creativity extends beyond music and can be applied to various subjects, such as writing, problem-solving, and even scientific experiments.Moreover, singing is an effective tool for improving language skills. Through singing, students are exposed to a wide range of vocabulary, idioms, and grammatical structures. They learn to pronounce words correctly, understand their meanings in context, and develop a senseof rhythm and intonation. Singing also helps students memorize information more easily, as melodies and rhythms create a memorable pattern that aids in retention.In addition, singing promotes social interaction among students. Whether it's singing in a choir, performing in a musical, or simply singing together in a classroom, students learn to work as a team and support each other. Singing requires cooperation, coordination, and active listening, fostering a sense of unity and belonging. It also provides a platform for students to showcase their talents and build confidence in their abilities.Furthermore, singing transcends cultural and linguistic barriers. It is a universal language that can be understood and appreciated by people from different backgrounds. Through singing, students can gain a deeper understanding and appreciation of diverse cultures and traditions. It promotes empathy, tolerance, and respect for others, fostering a global mindset and encouraging students to become responsible global citizens.In conclusion, singing plays a vital role in education. It stimulates creativity, enhances language skills, fosters social interaction, and promotes cultural understanding. By incorporating singing into educational settings, we can create a vibrant and engaging learning environment that nurtures the holistic development of students. So let's embrace the power of singing and let our voices be heard!。