当前位置：文档之家 › INTEGRATING OPNET WITH THE MRT TOOL KIT

INTEGRATING OPNET WITH THE MRT TOOL KIT

  • 格式：pdf
  • 大小：286.43 KB
  • 文档页数：6

Contact Information: Susan A. Powers spowers@ The MITRE Corporation 202 Burlington Road, MS B018 Bedford, MA 01730-1420 phone: 781-271-3575 fax: 781-271-2964INTEGRATING OPNET WITH THE MRT TOOL KITSusan A. Powers Raymond A. Modeen Dr. Mahmoud A. Makhlouf John H. James Stuart C. Schaffner The MITRE Corporation 202 Burlington Road, MS B018 Bedford, MA 01730-1420 spowers@ ABSTRACT MITRE is prototyping a capability to integrate OPNET with the Model Reference Technology (MRT) tool kit. This tool kit provides the capability to integrate architecture specification, design and analysis tools using a data repository. Central to MRT is the use of loop models based on Hierarchical Colored Petri Nets. We have found this loop-based modeling technique to be a powerful vehicle for specifying and documenting operational architectures and the network traffic flows that are derived from operational architectures. Our prototype system incorporates tools that create, store and access the architecture data represented by loop models. To further experiment with our approach, we integrated OPNET with our prototype and then used OPNET to simulate the network traffic loads represented by loop models. While our goal was to explore the area of tool integration, our repository-based prototype suggests some features that would be valuable in OPNET. These include visualizing application traffic flows using colored loops and separating the specification of logical traffic flows from the specification of physical network topology. INTRODUCTION The use of models is fundamental to the practice of all engineering disciplines. At the MITRE Corporation, models are used to document, communicate, simulate, and analyze the architecture of large government and military systems. The resulting models capture architecture data for many architecture levels. To provide a productive, collaborative working environment, data for different architecture levels must _____________________________________________ © 1999 The MITRE Corporation. All Rights Reserved.1be integrated into a single, consistent framework. This data must then be made available to a variety of project specialists using a variety of architecture tools. To address these needs, we are developing a modeling and simulation technology called the Model Reference Technology (MRT). This technology provides a modelbased systems engineering process supported by an integrated set of tools. A prototype of our tool integration framework has been developed and used, experimentally, to integrate a MITRE-developed architecture modeling tool with a COTS capacity planning tool. OPNET was the tool selected as our experiment example. MODEL REFERENCE TECHNOLOGY FRAMEWORK The center of the MRT framework (figure 1) is a data repository that captures data from all tools. The repository uses an integrated schema (data model) that represents and relates the data objects manipulated by each tool.Project Management ToolsSubSchemaArchitecture Modeling ToolsSubSchemaMRT Architecture Data RepositorySubSchemaRequirements Analysis ToolsSubSchemaCapacity Planning ToolsData Base Management ToolsSubSchemaIntegrated SchemaSubSchemaMission/Design Simulation ToolsTest Automation ToolsSubSchemaSubSchemaReverse Engineering ToolsMRT Architecture Specification Tool (MAST)Figure 1. MRT Tools Integration FrameworkEach tool stores or accesses the repository data that is relevant to its particular domain of application. Some tools will import data, some will export data, and some will need to do both. An MRT tool called MAST (MRT Architecture Specification Tool) is used to regulate these activities. MAST functionality is shown in figure 2.User Interfaces for other Tools LEdit GUI MAST GUImodels and OPNET's External Model Access (EMA) API. This API, with its ability to programmatically create, query and modify OPNET models, made OPNET particularly attractive for tool integration. MRT LOOP MODELING TECHNIQUE Fundamental to the MRT approach is the MRT Loop modeling technique. This technique uses colored loops to show both operational flows and data flows in a system. Each loop is named and is specified using a bipartite graph called a ÒLoopÓ diagram. (Figure 3). Associated with each node (in the loop) is an algorithm, a set of variables specifying the node's state and its operational parameters. Attribute sets can also be associated with node connections (edges) and with loops.Red LoopMRT Graphical Model Editor (LEdit) OPNETLEdit Palettes & Diagrams OPNET Model FilesDBMSArchitecture RulesMRT Architecture Rules Database Architecture Data Repository MRT Integrated SchemaMASTArchitecture DataOther MRT ToolsData for Other ToolsUpdated Architecture Data Client PC/Windows 95File Server PCFigure 2. MAST Tool Functionality MAST provides transparent storage and retrieval of architecture data from the repository. An MRT Architecture Rules Database is used to store a tablebased definition of the repository's schema. This approach makes it easy to adapt to schema extensions as new tools are incorporated. MASTÕs graphical user interface supports selection of data from the repository and selected data is exported to tools through a set of bridges. Each tool-specific bridge is based on a tooldefined external file format or a tool-supplied API. In this manner, each tool interfaces with the shared repository using its own tool-defined interface and presents data to the user through its own GUI. Several architecture tools have already been incorporated into the MRT framework. These include an MRT simulation tool (James 1992) that was successfully used to analyze, predict and validate, within an 8% error rate, the performance of a large communication system (Makhlouf, James, Giorgio 1993). Other MRT applications include sensitivity analysis and system migration of radar systems (Makhlouf 1993, 1995), simulation of the command and control subsystem of a space station (Lacovara 1993), distributed energy systems (Makhlouf 1994), and migration of mission critical systems (Makhlouf 1996). In our tool integration prototype, OPNET was selected as an example of a capacity planning tool. Features we found particularly useful for our experiment include OPNET's large, up-to-date library of protocol and deviceProcessing DataBlue LoopFigure 3. Loop Model We have found this modeling technique to be a valuable approach to architecture modeling at all levels. In operational architecture models that show activities and data flows, loops document and visualize mission threads and partition the operational architecture into Òuse casesÓ. In system architecture models, loops visualize process threads through system components and partition the system architecture into series of system builds. In network traffic flow models, loops visualize the traffic flow needed to support operational activities and loop attributes characterize traffic loads. OPNET TOOL INTEGRATION EXPERIMENT To specify and analyze network traffic, we integrated the MRT graphical modeling tool called LEdit with OPNET. By dividing the traffic modeling and analysis job between the two tools, we were able to capitalize on the strengths of each tool. LEdit is a flexible modeling tool that supports the specification and visualization of operational and system architectures using MRT loop models. We used LEdit to specify the system operational architecture and the network traffic flow model. We used OPNET to specify the detailed network model and perform network analysis. This approach has2the added benefit that it separates the specification of the logical traffic flow from the specification of the physical network topology. The approach we used to create traffic specification data in LEdit and move it via the MRT data repository to OPNET is shown in figure 4.- network delayLEditApplication Traffic Loop ModelMASTLEdit BridgeCreate Application Traffic ModelApplication Traffic Loop Model Repository Storage/Retrieval Interface OPNET Network Model File OPNET Network Model File with Application TrafficDBMSMRT MRT Architecture Architecture Data Data Repository Repositorycolored loops. For each application traffic path, a client application process is connected to the associated server process using a directed loop with the client as the initial loop node and the server as the terminal loop node. An application-specific set of attributes quantifying the traffic load is attached to each loop. When multiple clients are communicating with a single server using the same traffic load, a loop can be constructed with more than one initial node. Note that LEdit's embedded hierarchy makes it possible to graphically connect client and server elements that may be in different subnetworks. In OPNET, a full network topology model is created, with no application traffic specified. Care is taken is assign names to traffic source and destination nodes that match the node names used in the MRT traffic model. To prepare for a network analysis run with a particular application traffic model, MAST retrieves the traffic model of interest from the MRT repository. The traffic data is then passed to an OPNET-specific data bridge that reads the corresponding OPNET model, adds application traffic data provided by the traffic model to the appropriate OPNET network nodes and saves the updated OPNET model. Network analysis is performed by OPNET on the updated model and the analysis results are stored. OPNET TOOL INTEGRATION PROTOTYPE The design of our prototype tool integration system is shown in figure 6.Tool-Specific Processing OPNET Model Files EMA APIOPNETCreate Network Topology Model Perform AnalysisApplication Traffic Loop ModelApplication Traffic Loop Model OPNET Bridge (using EMA API)Analysis Results - link utilization - network delayFigure 4. LEdit-OPNET Traffic Data Integration An application traffic model created in LEdit is imported by MAST's LEdit bridge and stored in the MRT repository. To analyze and compare a variety of traffic flow options, a different traffic model can be prepared for each option and the complete set of models can be stored in the repository. An example of the way we use MRT loop models to model two-tier (client-server) application traffic is shown in figure 5.MRT-Based Architecture Rules Processing Model Verification MRT ModelOPNET (EMA) ModelsValidated DataDBMS DBMS MRT Architecture Rules Database MRT Architecture Data Repository MRT Integrated Schema File Server PCOPNET OPNETText streamTool-Specific BridgesRepository Storage/ Retrieval Interface (ODBC)Architecture Rules Architecture Data Updated Architecture DataMRT DataMRT API Architecture Data Directory Data Selection FunctionLEdit Model Files MRT Graphic EditorLEdit Models & Palettes(LEDIT)Active X Server Desktop PCIntegrated Graphic Editor Interface (Active X Client) Text streamMASTDesktop PCMRT Loop Model Editing & Visualization OPNET Model Editing & Performance AnalysisFigure 5. Sample Application Traffic Loop Model This model specifies the network client/server nodes and the application processes running at these nodes. Application traffic flow is graphically modeled usingFigure 6. Prototype Design The central MAST tool divides its functionality into two integrated processing components. One component3provides repository storage and retrieval operations for all tools. This component only deals with "MRT models", models constructed according to the MRT repository's integrated schema (data model). The second component encompasses a set of tool-specific bridges that construct, access and modify MRT models through a MAST-defined "MRT API". One toolspecific bridge is provided for each member of the MRT tool kit. Each bridge encapsulates the mapping needed to translate and exchange data between the MRT integrated schema and the target tool's internal schema. In our experiment with OPNET, the MRT integrated schema is used to associate each loop with a set of application-specific traffic attributes as shown in figure 7.... is associated with is subtype of HTTP Traffic S pec FTP Traffic S pec E-Mail Traffic S pecoperations provided by the EMA API and the MRT API are used to locate the client/server nodes in the network model that match the traffic-generating client/server nodes in the traffic model. Next, for each set of matching nodes, the traffic specs applicable to the node are extracted from the traffic model and, using EMA attribute setting operations, the appropriate application traffic attributes for the corresponding node are set in the OPNET model. When all traffic data has been exported, the updated OPNET model is saved as an OPNET model file. As indicated above in Figure 4, this updated model is then analyzed by OPNET and the analysis results are stored. A natural extension to our prototype would be to store these performance results back in the MRT repository for use by other tools. CONSIDERATIONS FOR OPNET Specification of traffic flows is a critical part of network capacity planning. While our goal was to explore the area of tool integration, our experiment identified a few areas where OPNET's approach to traffic specification could be improved. One recommendation is to separate the specification of logical traffic flows from the detailed physical view of the network topology. Currently in OPNET, application traffic must be specified using tabular forms that are tied to the multi-window view of the detailed network topology. A suggested alternative is to specify application traffic using a separate flat view showing all potential source/destination nodes. This concept is similar to the Traffic Browser window used for background routed traffic. With this type of simple network view, OPNET could provide a more graphical point-and-click method of connecting clients to servers. This approach can also be extended to permit a variety of logical traffic alternatives to be created, archived and applied to a single network topology for comparison. A natural companion to this approach is a built-in capability for importing application traffic from an external source. A second recommendation is to provide a way of visualizing traffic flows. Regardless of the method used to specify application traffic, colored loops (threads) could be used in the network topology view as a visual record of traffic flow paths. This approach could be used to represent both simple 2-tier application traffic flows and the more complex multi-tier flows now supported by OPNET 6.0. By adding a color setting to the 2-tier attribute list or the multi-tier traffic profile, the user could control the colors assigned to each loop. A "right-click" action applied to loop objects could also4LoopTraffic S pecis associated withparticipates inClient/ erver S Processruns onNetwork NodeFigure 7. Traffic Specifications in the MRT Schema The OPNET bridge adds this traffic data to the OPNET network model. The processing performed by this bridge is shown in Figure 8.OPNET BridgeMASTOPNET Network Model FileEMA APIEMA Network ModelApplication Traffic DataMRT APIApplication Traffic Loop Model Application Traffic Integration Function (using EMA API)OPNET Network Model File with Application TrafficEMA APIEMA Network Model with Application TrafficRepository Storage/Retrieval InterfaceFrom RepositoryFigure 8. OPNET Traffic Data Bridge First, the MRT application traffic loop model and the OPNET network model are retrieved. Second, queryprovide a convenient means of displaying the parameters associated with a traffic flow. A final suggestion is to provide a way of verifying application traffic client-to-server paths prior to a simulation run. When application traffic server selections are made externally through EMA or through the current tabular application traffic specification technique, selection of a non-existent or physically unreachable server is not reported. By providing a graphical means of specifying or visualizing application traffic paths, such errors could be detected or avoided. CONCLUSIONS A repository-based tool integration approach can provide a useful means of combining the capabilities of various tools. In the particular area of network traffic analysis, MRT loop technology provides a valuable capability for graphically visualizing network traffic flows. By using the MRT tool integration framework to integrate this traffic modeling capability with the network analysis capabilities of OPNET, we have been able to combine key features of two tools to perform network capacity planning.Engineering Approach for the Migration of Computer-Based Systems, INCOSEREFERENCESJames, J., May 1, 1992. ÒState-Machine Paradigm for Software Performance Simulation: MSim Implementation.Ó In Proceedings of the 23rd Annual Modeling and Simulation Conference (Pittsburgh, Pennsylvania, April 30 - May 1). Lacovara, R., July 1993. ÒApplication of a New Simulation Tool to a Command and Control Subsystem of the Space Station Freedom.Ó In Proceedings of 1993 Summer Computer Simulation Conference (Boston, Massachusetts, July 19-21). Makhlouf, M., Giorgio, P., July 1993. ÒPerformance Analysis Models of Distributed Radar Systems.Ó In Proceedings of 1993 Summer Computer Simulation Conference, Boston, MA. Makhlouf, M., April 1994. ÒSensitivity Analysis of Functionally Distributed Energy Management Systems.Ó In Proceedings of 1994 SCS Simulation Multi-conference, LaJolla, CA. Makhlouf, M., James, J., Wigfield, E., Wheeler, T., Modeen, R., Schaffner, S., Ó, July 1996, ÒA System5。

合集下载

恩智浦S32R274汽车雷达处理器应用指南说明书

恩智浦S32R274汽车雷达处理器应用指南说明书

by:NXP Semiconductors1Introduction The S32R274 is a 32-bit Power Architecture ® based Microcontroller (MCU) unitfor automotive applications. It extends the MPC5775K family by a value deviceoptimized for surround RADAR sensors and midrange front RADAR sensors.The family members are designed to address advanced RADAR signalprocessing capabilities and merge it with microcontroller capabilities forgeneric software tasks and car bus interfacing.S32R274 meets the high performance computation demands required by modern beamforming fast chirp modulation RADAR systems by offering unique signal processing acceleration together with powerful multi-core architecture.The S32R274 supports automotive safety applications that require a highSafety Integrity Level (ASIL) and adds SHE compliant security features toprevent unauthorized manipulations. The high integration level of S32R274 enables the customer to build compact, safe and secure, low cost RADAR sensors with leading edge performance. The family members have a high level of software compatible for shared hardware modules.S32R274 is a high end automotive MCU designed to support computation intensive application, like ADAS RADAR.Figure 1.RADAR application overview2Signal Processing Toolbox (SPT) in S32R familyIn radar signal processing or acceleration, Signal Processing T oolbox (SPT) and Z7 SIMD units are used.•Accelerated hardware FFT , vector math, peak search, statistics•Generic DSP functionality with SPE and VFPU unit of Z7 coresSignal Processing T oolbox (SPT) contains all the hardware modules required for processing of the sampled RADAR signals. It is a powerful processing engine containing high-performance signal processing operations, driven by a specific use-orientedinstruction set. The programmability ensures flexibility for modifications of signal processing. The CPU is removed from frequent scheduling of hardware operations, but still controls and interacts with the processing flow.Contents1 Introduction (1)2 Signal Processing Toolbox (SPT)in S32R family....................................13 SPT execution......................................34 SPT internal memory...........................45 Common instruction fields.................46 SPT programming................................47 Conclusion. (6)8 Reference.............................................7AN12424SPT Programming on S32R Rev. 0 — May 2019Application NoteSPT is connected to the device by an advanced high performance master bus and a peripheral bus.Figure 2.SPT in S32R274 block diagramThe system bus master interface performs fast data transfers between external memory and local RAM.The purpose of the peripheral interface is to set configuration, get status information and basic control of SPT (start/stop, program pointer) and to trigger interrupts. It can also be used to exchange small amounts of the data between the CPU and the SPT , such as constant operands.Figure 3.SPT block diagramIt has the following features:•Acquisition of ADC samples—Capturing of ADC samples within programmed window—On-the-fly statistical computation—Supports MIPICSI2 interface•Provides HW acceleration for—FFT (8 - 4096 point)—Histogram calculation—Maximum and peak searchSignal Processing Toolbox (SPT) in S32R family—Mathematical operations on vector data•High-speed DMA data transfer—Supports system RAM, TCM and Flash memory transfers—Includes compression/decompression capability for reduction of storage footprint•Instruction based program flow—High-level commands for signal processing operations—Simple control commands—Local instruction buffer—Automatic instruction fetch from main memory—CPU interaction possible•CPU interruption notification•Watchdog•Debug Support - Single Stepping and Jamming ModeIt has three operation modes:1.STOP mode2.System Debug mode3.Normal mode3SPT executionThe SPT executes a list of instructions. These commands contain all the information to perform signal processing operations on data vectors consisting of a set of numbers. The instruction list is provided by the CPU in a memory buffer (SRAM or flash) and read by the SPT with autonomous triggered DMA operations. Preparation of command scripts is performed off-line duringdevelopment on a different system, such as a PC.Figure 4.SPT operation modelData as results or inputs of signal processing operations can be transferred between operand/twiddle RAM and system RAM or TCM by DMA operations. These kind of DMA operations are also scheduled by commands in the script.CPU application software functions may be invoked between signal processing operations. In order to synchronize these SW functions with the processing flow, interrupts and polling flags are provided, which may be activated as a result of specificcommands. In the same way, eDMA operations can be triggered from the SPT . The data transfer descriptors need to be prepared by application software.T o enable advanced and precisely timed pipelining of HW assisted operations, SPT command execution can also be synchronized with or triggered by events from CTE or MIPICSI2.SPT executionSPT internal memoryProgram execution is performed by a dedicated register machine. The program execution may be stalled at the end of each command and can be synchronized with events provided by the CTE or MIPICSI2. The CPU can stop and release program execution and execute its own instructions in the same time.The SPT command sequence is provided by CPU SW and written to a buffer in the system RAM or flash, where CSDMA fetches or alternatively transfers the list of instructions to the command queue.The program is executed sequentially, one command following the next in the chain with the exception being loops and asynchronous PDMA instruction. The end of a sequence is marked with a specific termination command. The start address of the instruction sequence is configured by application software using the peripheral interface.The command queue stores a number of instructions to be executed, which may be a shorter sequence than the complete instruction list. It maintains an instruction pointer to the current executed operation, which is incremented when the current operation is completed. This instruction pointer indicates the position in the complete instruction list sequence relative to the first instruction.Loop instructions are special cases, the program sequence may continue with a lower address depending on the state of the loop counter. The start and next command address of the loops are saved in special registers. Up to four nested loops are supported. Jump instructions or branch instructions are another case where the program may cause the program to branch to a non-contiguous address location. It is the responsibility of the assembler to ensure that the sanity of the program structure is not violated i.e. infinite loops, jumping into or out of a loop, etc.4SPT internal memorySPT contains internal memory resources namely, Operand RAM, Twiddle RAM and work registers. Out of these, only the work registers can be directly accessed via the peripheral interface and are visible on the SPT external memory map.The CPU can access these internal memory resources via the hardware accelerators. The instruction bitfields SRC_ADD and DEST_ADD point to these memories.The Twiddle RAM extends from location 0x4000 to 0x4FFF. However the area from 0x5000 to 0x7FFF is aliased to the Twiddle RAM i.e. it wraps around to point to the T widdle RAM. It should be noted that the memory accesses to the T widdle RAM should not cross the area from 0x4000 to 0x7FFF.The Operand RAM extends from location 0x8000 to 0xBFFF. But the area from 0xC000 to 0xFFFF is aliased to the Operand RAM. The memory accesses to the Operand RAM should not cross the area from 0x8000 to 0xFFFF.5Common instruction fieldsCommon instructions contains the following fields.•Opcode•Source and Destination address•Indirect Memory address•Source and destination address increment•Vector size•Input datatype/preprocessing6SPT programming6.1Programming based on RSDKNXP Radar SDK(RSDK) provides basic radar processing algorithms and device drivers for S32R hardware devices. Its purpose is to facilitate radar algorithm development (using SPT kernels, MA TLAB models), creation of higher level algorithms (starting from the basic blocks supplied with RSDK) and easy application development by integrating driver and platform support.Radar SDK (Radar SDK for S32R27 SPT accelerator ) could be downloaded from NXP website.RSDK SPT module consists of the SPT Driver, SPT Kernels software components.The SPT Driver serves as an interface between the user application running on the host CPU cores and the SPT hardware. The figure below shows a high-level block diagram of SPT software architecture. Its purpose is to enable the integration and executionof low-level microcode kernels on the SPT (Signal Processing T oolbox) accelerator for baseband radar signal processing.Figure 5.SPT software architectureThe SPT Kernels are individual precompiled routines of SPT code packed into a library, each implementing a part of the radar processing flow.T ogether, the SPT Driver and SPT Kernels library provide a software abstraction of the built-in SPT hardware functions (e.g. FFT ,Maximum Search, Histogram etc.) combined in a series of algorithms.The RSDK package also includes RSDK Sample Applications showing how to integrate these software components into the user code.6.2Programming based on graphic toolS32 Design Studio SPT graphical tool allows user to use graphical modeling workbench by leveraging the Eclipse Modeling technologies. It provides a workbench for model-based architecture engineering. Graphical tool equips teams who have to deal with complex architectures. The graphical tool includes everything necessary to easily create and manipulate models. The output of this tool is SPT assembler source code.The SPT graphical tool is integrated with the New S32DS Project wizard for devices which have SPT module. SPT1, SPT2 and SPT2.5 versions of SPT modules are supported. The SPT graphical tool can be used after project creation with the new graph tools project wizard. For detailed description of new project wizards, please read S32 Design Studio for Power Architecture, Version 2017.R1 reference manual.After the project is generated, SPT graphical tool windows could be gotten in IDE. User could drag 'Instructions', 'Flow' and 'Directives' from Palette window into working flow window.SPT programmingEach 'Instructions', 'Flow' or 'Directives' could change their setting in properties window. After finished the design of SPT working flow, generate SPT code through right click mouse.Figure 6.Generate project with SPT graphical toolFigure 7.SPT graphical tool windowsFigure 8.Example working flow and generate code7ConclusionThe SPT is a powerful processing engine containing high-performance signal processing operations driven by a specific instruction set. Its programmability ensures flexibility while removing the CPU from frequent scheduling of hardware operations, while still controlling and interacting with the processing flow. RSDK supports the API of SPT for customer and graphics tool for SPT programming could meet the flexible design request.8Reference•S32R274 Reference Manual•Radar SDK for S32R27 SPT accelerator •AN5375, S32R RADAR Signal CompressionHow To Reach Us Home Page: Web Support: /support Information in this document is provided solely to enable system and software implementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein.NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. “Typical” parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including “typicals,” must be validated for each customer application by customer's technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: / SalesTermsandConditions.While NXP has implemented advanced security features, all products may be subject to unidentified vulnerabilities. Customers are responsible for the design and operation of their applications and products to reduce the effect of these vulnerabilities on customer’s applications and products, and NXP accepts no liability for any vulnerability that is discovered. Customers should implement appropriate design and operating safeguards to minimize the risks associated with their applications and products.NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, COOLFLUX, EMBRACE, GREENCHIP, HIT AG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE CLASSIC, MIFARE DESFire, MIFARE PLUS, MIFARE FLEX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, ST ARPLUG, TOPFET, TRENCHMOS, UCODE, Freescale, the Freescale logo, AltiVec, C‑5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C‑Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, SMARTMOS, Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service names are the property of their respective owners. AMBA, Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex, DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView, SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINK-PLUS, ULINKpro, µVision, Versatile are trademarks or registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and word marks and the Power and logos and related marks are trademarks and service marks licensed by .© NXP B.V. 2019.All rights reserved.For more information, please visit: Forsalesofficeaddresses,pleasesendanemailto:**********************Date of release: May 2019Document identifier: AN12424。

融合决策树与注意力模型的可解释apt检测方法

融合决策树与注意力模型的可解释apt检测方法

文章标题：融合决策树与注意力模型的可解释apt检测方法1. 引言在当今的信息时代，隐私和安全问题越来越受到人们的关注。

随着人工智能和机器学习技术的不断发展，可解释性也成为了一个极为重要的问题。

在安全领域，可解释的APT（高级持续性威胁）检测方法尤为重要。

本文将介绍一种将决策树和注意力模型融合的方法，用于可解释的APT检测。

2. 对决策树的深入剖析决策树是一种常用的机器学习模型，其简单直观的特点使其在可解释性方面具有一定优势。

决策树通过对特征的重要性进行排序，逐层划分数据集，最终形成一个树状结构。

然而，传统的决策树模型在处理复杂数据时容易出现过拟合的问题，因此需要结合注意力模型进行优化。

3. 注意力模型的作用和意义注意力模型源自自然语言处理领域，其作用是对输入的不同部分赋予不同的权重，以便模型更好地关注重要的信息。

在进行APT检测时，注意力模型能够帮助模型更好地捕捉到威胁行为的特征，提高模型的鲁棒性和准确性。

4. 融合决策树与注意力模型的方法及优势融合决策树与注意力模型的方法即是在决策树的基础上引入注意力机制，使得模型在进行预测时能够更加关注重要的特征。

通过对不同特征赋予不同的注意力权重，模型可以在保持决策树的可解释性的提高预测性能和对威胁的捕捉能力。

5. 实例分析举例来说，如果我们将决策树和注意力模型应用于网络流量的APT检测中，决策树可以通过逐层划分特征来判断是否存在威胁行为，而注意力模型可以帮助模型更加关注网络流量中的异常行为，提高检测的准确性和鲁棒性。

6. 个人观点和理解个人认为，融合决策树与注意力模型的方法在可解释性和预测性能之间寻找到了一个良好的平衡点，能够提高模型对APT的检测能力。

这种融合方法对于安全领域具有非常重要的意义，能够帮助安全团队更好地理解威胁行为，提高安全防御的效果。

7. 总结与回顾融合决策树与注意力模型的可解释APT检测方法不仅结合了决策树的可解释性和注意力模型的预测性能，同时也在安全领域有着广泛的应用前景。

G.823-以2048kbs系列等级为基础的数字网内抖动和漂动的控制

G.823-以2048kbs系列等级为基础的数字网内抖动和漂动的控制

INTERNATIONAL TELECOMMUNICATION UNIONG.823(03/2000) TELECOMMUNICATIONSTANDARDIZATION SECTOROF ITUSERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKSDigital networks – Quality and availability targetsThe control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchyITU-T Recommendation G.823(Formerly CCITT Recommendation)ITU-T G-SERIES RECOMMENDATIONSTRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199G.200–G.299 GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMSINDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONEG.300–G.399 SYSTEMS ON METALLIC LINESG.400–G.449 GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONESYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITHMETALLIC LINESCOORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499 DIGITAL NETWORKS G.800–G.899 General aspects G.800–G.809 Design objectives for digital networks G.810–G.819 Quality and availability targets G.820–G.829 Network capabilities and functions G.830–G.839 SDH network characteristics G.840–G.849 Management of transport network G.850–G.859 SDH radio and satellite systems integration G.860–G.869 Optical transport networks G.870–G.879 DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999For further details, please refer to the list of ITU-T Recommendations.ITU-T Recommendation G.823The control of jitter and wander within digital networkswhich are based on the 2048 kbit/s hierarchySummaryThis ITU-T Recommendation specifies the maximum network limits of jitter and wander that shall not be exceeded and the minimum equipment tolerance to jitter and wander that shall be provided at any relevant transport or synchronization interfaces which are based on the 2048 kbit/s hierarchy. The requirements for the jitter and wander characteristics that are specified in this ITU-T Recommendation must be adhered to in order to ensure interoperability of equipment produced by different manufacturers and a satisfactory network performance.SourceITU-T Recommendation G.823 was revised by ITU-T Study Group 13 (1997-2000) and approved under the WTSC Resolution 1 procedure on 10 March 2000.KeywordsClocks, Input Jitter Tolerance, Input Wander Tolerance, Network Limits, Output Jitter, Output Wander, Synchronization, Timing.ITU-T G.823 (03/2000) iFOREWORDThe International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.The approval of ITU-T Recommendations is covered by the procedure laid down in WTSC Resolution 1.In some areas of information technology which fall within ITU-T’s purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.NOTEIn this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database.ã ITU 2001All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. ii ITU-T G.823 (03/2000)CONTENTSPage1 Scope (1)2 References (2)3 Definitions (2)4 Abbreviations (3)5 Network limits for traffic interfaces (4)5.1 Network limits for output jitter at traffic interfaces (4)5.2 Network limits for output wander at traffic interfaces (5)5.2.1 2048 kbit/s interface output wander limit (6)5.2.2 34 368 kbit/s interface output wander limit (7)5.2.3 139 264 kbit/s interface output wander limit (8)6 Network limits for synchronization interfaces (8)6.1 Network limits for output jitter at synchronization interfaces (9)6.2 Network limits for output wander at synchronization interfaces (9)6.2.1 PRC interface output wander limit (10)6.2.2 SSU interface output wander limit (11)6.2.3 SEC interface output wander limit (13)6.2.4 PDH synchronization interface output wander limit (14)7 Jitter and wander tolerance of network interfaces (16)7.1 Jitter and wander tolerance of traffic interfaces (16)7.1.1 64 kbit/s input jitter and wander tolerance (17)7.1.2 2048 kbit/s input jitter and wander tolerance (18)7.1.3 8448 kbit/s input jitter and wander tolerance (19)7.1.4 34 368 kbit/s input jitter and wander tolerance (20)7.1.5 139 264 kbit/s input jitter and wander tolerance (21)7.2 Jitter and wander tolerance of synchronization interfaces (22)Annex A − Network model underlying the synchronization network limit (22)A.1 Introduction (22)A.2 Considerations on the network model (22)A.3 Information regarding the simulations (25)Annex B − Network wander reference model and parameters (26)B.1 Wander reference model for traffic interfaces (26)B.1.1 Asynchronous PDH connection (26)B.1.2 Synchronous PDH connection (27)B.1.3 Specification of wander by MRTIE parameter (27)ITU-T G.823 (03/2000) iiiPage B.2 Wander reference model for synchronization interfaces (28)B.2.1 Specification of wander by MTIE and TDEV parameters (30)Appendix I − Wander limit considerations for SDH transport networks (30)I.1 Introduction (30)I.1.1 Wander reference model for SDH (30)I.1.2 Sources of wander (31)I.1.3 Wander accumulation limiting effects (32)I.1.4 Network configuration and performance (32)I.1.5 Correlation of wander sources (32)I.1.6 Network conditions for the output wander limits (32)I.2 Derivation of wander specification limits (33)I.2.1 Wander specification limits (34)Appendix II − Measurement methodologies for output wander (34)interfaces (34)II.1 SynchronizationII.1.1 Synchronous signals (34)interfaces (35)II.2 TrafficII.2.1 Synchronous signals (PDH bit-rates) (35)II.2.2 Asynchronous signals (PDH bit-rates) (36)Appendix III − Measurement guidelines for input jitter and wander tolerance of equipment interfaces (38)iv ITU-T G.823 (03/2000)Introduction and backgroundIn a digital network, jitter and wander accumulate on transmission paths according to the jitter and wander generation and transfer characteristics of each equipment interconnected. This equipment may be different types of multiplexers/demultiplexers, cross-connects, clocks and line systems, for example.An excessive amount of jitter and wander can adversely affect both digital (e.g. by generation of bit errors, slips and other abnormalities) and analogue signals (e.g. by unwanted phase modulation of the transmitted signal). The consequences of such impairment will, in general, depend on the particular service that is being carried and the terminating or adaptation equipment involved.It is therefore necessary to set limits on the maximum magnitude of jitter and wander, and the corresponding minimum jitter and wander tolerance at network interfaces, in order to guarantee a proper quality of the transmitted signals and a proper design of the equipment. These network limits are independent of the particular service that is being carried.ITU-T G.823 (03/2000) vITU-T Recommendation G.823The control of jitter and wander within digital networkswhich are based on the 2048 kbit/s hierarchy1 ScopeThis ITU-T Recommendation specifies the relevant parameters and their limiting values that are able to satisfactorily control the amount of jitter and wander present at Network Node Interfaces (NNI) of Plesiochronous Digital Hierarchy (PDH) and synchronization networks which are based on the first-level hierarchical bit rate of 2048 kbit/s.This ITU-T Recommendation also specifies the jitter and wander requirements at PDH User-Network Interfaces (UNI). However, particular terminals or services may have additional jitter and wander requirements and in those cases the relevant ITU-T Recommendations shall apply. Requirements for NNI of PDH and synchronization networks which are based on the first-level hierarchical bit rate of 1544 kbit/s are specified in ITU-T Recommendation G.824 and requirements for Synchronous Digital Hierarchy (SDH) NNI are specified in ITU-T Recommendation G.825.The jitter and wander requirements specified in this ITU-T Recommendation are applicable to the interfaces irrespective of the underlying transport mechanism (PDH, SDH or ATM networks, for example).The jitter and wander requirements for an interface will be different, depending on whether the signal at the interface is used to transport traffic and/or synchronization. The requirements for both traffic and synchronization interfaces are specified in this ITU-T Recommendation in the appropriate clauses.A synchronization network that conforms to the network limits for jitter and wander specified in this ITU-T Recommendation will be suitable for the synchronization of SDH and Public Switched Telephone Network (PSTN) networks.This ITU-T Recommendation also specifies the jitter and wander requirements for interfaces using the generic frame structures at PDH rates as defined in ITU-T Recommendation G.832.The electrical characteristics of the relevant PDH network interfaces are defined in ITU-T Recommendation G.703.The jitter and wander control philosophy of this ITU-T Recommendation is based on the need:a) to specify a maximum network limit of jitter and wander that shall not be exceeded at anyrelevant interface;b) to specify a minimum equipment tolerance to jitter and wander that shall be provided at anyrelevant interface;c) to establish a consistent framework for the specification of individual digital equipmenttypes; andd) to provide sufficient information and guidelines for organizations to measure and study jitterand wander characteristics in any network configuration.ITU-T G.823 (03/2000) 12 ReferencesThe following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.– ITU-T Recommendation G.703 (1998), Physical/electrical characteristics of hierarchical digital interfaces.– ITU-T Recommendation G.707 (1996), Network node interface for the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.783 (1997), Characteristics of Synchronous Digital Hierarchy (SDH) equipment functional blocks.– ITU-T Recommendation G.803 (2000), Architecture of transport networks based on the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.810 (1996), Definitions and terminology for synchronization networks.– ITU-T Recommendation G.811 (1997), Timing characteristics of primary reference clocks. – ITU-T Recommendation G.812 (1998), Timing requirements of slave clocks suitable for use as node clocks in synchronization networks.– ITU-T Recommendation G.813 (1996), Timing characteristics of SDH equipment slave clocks (SEC).– CCITT Recommendation G.822 (1988), Controlled slip rate objectives on an international digital connection.– ITU-T Recommendation G.824 (2000), The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy.– ITU-T Recommendation G.825 (2000), The control of jitter and wander within digital networks which are based on the Synchronous Digital Hierarchy (SDH).– ITU-T Recommendation G.832 (1998), Transport of SDH elements on PDH networks – Frame and multiplexing structures.– ITU-T Recommendation O.150 (1996), General requirements for instrumentation for performance measurements on digital transmission equipment.– ITU-T Recommendation O.171 (1997), Timing jitter and wander measuring equipment for digital systems which are based on the Plesiochronous Digital Hierarchy (PDH).– ITU-T Recommendation O.172 (1999), Jitter and wander measuring equipment for digital systems which are based on the Synchronous Digital Hierarchy (SDH).3 DefinitionsThis ITU-T Recommendation defines the following terms. Additional definitions relating to synchronization networks are provided in ITU-T Recommendation G.810, whilst the architectural principles of synchronization networks are described in ITU-T Recommendation G.803. Information regarding the wander reference models used in this ITU-T Recommendation is provided in Annexes A and B.2ITU-T G.823 (03/2000)interface: These interfaces provide an output signal with frequency that is 3.1 synchronousnormally traceable to a PRC.interface: These interfaces provide an output signal with frequency that is 3.2 asynchronousnot traceable to a PRC and that meets the frequency offset requirements given in ITU-T Recommendation G.703.interface: These interfaces may be asynchronous or synchronous and network jitter 3.3 trafficand wander limits are specified using the Maximum Relative Time Interval Error (MRTIE) parameter in this ITU-T Recommendation. Input jitter and wander tolerance is also specified in this ITU-T Recommendation. This interface category can be further sub-divided as follows:a) Interface is not able to provide synchronization, and is not required to. An example is aninterface supporting only 34 368 or 139 264 kbit/s PDH signals according to ITU-T Recommendation G.703.b) Interface is not able to provide synchronization at the defined performance level, butnevertheless is used to provide timing to other network elements such as terminal equipment, remote concentrators, etc. Examples include 2048, 34 368 and 139 264 kbit/s PDH signals transported on SDH, which may be subject to pointer justifications. ITU-T Recommendation G.803 recommends that these interfaces are not to be used for synchronization.c) Interface is able to provide synchronization at the defined performance level, in which caseit is defined to be a synchronization interface. An example is a synchronization interface operating at 2048 kbit/s. This sub-category may also include interfaces using the generic frame structures at PDH rates as defined in ITU-T Recommendation G.832.interface: These interfaces are synchronous and network wander limits are 3.4 synchronizationspecified using Maximum Time Interval Error (MTIE) and Time Deviation (TDEV) parameters with values given in this ITU-T Recommendation. The input jitter and wander tolerance of clock equipment ports is specified in other Recommendations (refer to 7.2).4 AbbreviationsThis ITU-T Recommendation uses the following abbreviations. Additional abbreviations relating to synchronization networks are provided in ITU-T Recommendation G.810.ATM Asynchronous Transfer ModeAU-n Administrative Unit, level nCLK ClockCMI Coded Mark InversionITU-T International Telecommunication Union – Telecommunication Standardization SectorFilterLPF Low-PassMRTIE Maximum Relative Time Interval ErrorMS-AIS Multiplex Section Alarm Indication SignalMTIE Maximum Time Interval ErrorElementNE NetworkNNI Network Node InterfacePDH Plesiochronous Digital Hierarchypk-pk peak-to-peakPLL Phase Locked Loopppm parts per millionPRBS Pseudo-Random Binary SequencePRC Primary Reference ClockPSTN Public Switched Telephone NetworkRMS Root Mean SquareRTIE Relative Time Interval ErrorSDH Synchronous Digital HierarchySEC SDH Equipment ClockSSU Synchronization Supply UnitSTM-N Synchronous Transport Module, level NTDEV Time DeviationTIE Time Interval ErrorTU-m Tributary Unit, level mIntervalUI UnitUIpp Unit Interval, peak-to-peakInterfaceUNI User-NetworkUTC Universal Time CoordinatedVC-n Virtual Container, level n5 Network limits for traffic interfaces5.1 Network limits for output jitter at traffic interfacesThe limits given in this clause represent the maximum permissible levels of jitter at interfaces within a digital network. Jitter as measured over a 60 second interval shall not exceed the limits specified in Table 1, when using the specified measurement filters.There is a close relationship between network limits and input tolerance such that the jitter measurement filter cut-off frequencies used in this clause have the same values as the jitter tolerance mask corner frequencies used in 7.1. Appendix I/G.825 has further information regarding this relationship.The limits given in Table 1 shall be met for all operating conditions and regardless of the amount of equipment preceding the interface. In general, these network limits are compatible with the minimum tolerance to jitter that all equipment input ports are required to provide.The functional description for measuring output jitter at a digital interface is provided in ITU-T Recommendation O.172.The high-pass measurement filters of Table 1 have a first-order characteristic and a roll-off of 20 dB/decade. The low-pass measurement filters have a maximally-flat, Butterworth characteristic and a roll-off of –60 dB/decade. Further specifications for the frequency response of the jitter measurement function such as measurement filter accuracy and additional allowed filter poles are given in ITU-T Recommendation O.172.Instrumentation in accordance with ITU-T Recommendations O.172 and O.171 is appropriate for measurement of jitter in SDH and PDH systems, respectively.NOTE − ITU-T Recommendation O.172 includes test set specifications for the measurement of SDH tributaries operating at PDH bit rates, where the test set requirements are more stringent than those relating only to PDH systems. Therefore, instrumentation in accordance with ITU-T Recommendation O.172 shall be used at PDH interfaces in SDH systems.Table 1/G.823 − Maximum permissible jitter at traffic interfacesInterfaceMeasurementbandwidth,–3 dB frequencies (Hz)Peak-to-peak amplitude(UIpp) (Note 3)64 kbit/s 20 to 20 k 0.25(Note 1) 3 k to 20 k 0.052048 kbit/s 20 to 100 k 1.518 k to 100 k (Note 2) 0.28448 kbit/s 20 to 400 k 1.53 k to 400 k (Note 2) 0.234 368 kbit/s 100 to 800 k 1.510 k to 800 k 0.15139 264 kbit/s 200 to 3.5 M 1.510 k to 3.5 M 0.075NOTE 1 − For the codirectional interface only.NOTE 2 − For 2048 kbit/s and 8448 kbit/s interfaces within the network ofan operator, the high-pass cut-off frequency may be specified to be 700 Hz(instead of 18 kHz) and 80 kHz (instead of 3 kHz) respectively. However, atinterfaces between different operator networks, the values in the table apply,unless involved parties agree otherwise.NOTE 3 –64 kbit/s 1 UI = 15.6 µs2048 kbit/s 1 UI = 488 ns8448 kbit/s 1 UI = 118 ns34 368 kbit/s 1 UI = 29.1 ns139 264 kbit/s 1 UI = 7.18 ns5.2 Network limits for output wander at traffic interfacesThe MRTIE specifications given in this subclause are intended for application to both asynchronous and synchronous PDH interfaces. Refer to Figures B.1 and B.2, respectively, for the reference network configurations. In the case of asynchronous interfaces, a frequency offset within the limits specified in ITU-T Recommendation G.703 is permitted, in addition to the wander specified in the following subclauses.It is required that, within a synchronized network, digital equipment provided at nodes shall accommodate permitted phase deviations on the incoming signal, i.e. under normal synchronized conditions, impairments will not occur.However, it should be recognized that, as a result of some performance degradations, failure conditions, maintenance actions and other events, the phase difference between the incoming signal and the internal timing signal of the terminating equipment may exceed the jitter and wander tolerance of the equipment which may result in an abnormal event such as a slip or bit-error burst.In addition, at a node which connects to an independently-synchronized network (or where plesiochronous operation is used in national networks), the phase difference between the incoming signal and the internal timing signal of the terminating equipment may eventually exceed the wander tolerance of the equipment in which case an abnormal event such as a slip may occur. The maximum permissible long-term mean controlled slip rate resulting from this mechanism is derived from the clock performance defined in ITU-T Recommendation G.811, i.e. no more than one slip in 70 days. NOTE − The wander specifications defined in the following subclauses are consistent with the derivation of network limits described for the case of SDH network transport in Appendix I.The wander measurement requirements (e.g. sampling time and measurement interval) for MTIE, MRTIE and TDEV parameters, the 10 Hz wander measurement filter characteristic and the functional description for measuring output wander are described in ITU-T Recommendation O.172. Instrumentation in accordance with ITU-T Recommendation O.172 is appropriate for measurement of wander parameters.Measurement methodologies used to measure the MRTIE parameter are described in Appendix II. 5.2.1 2048 kbit/s interface output wander limitThe maximum level of wander that may exist at a 2048 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 2. The resultant overall specification is illustrated in Figure 1.Table 2/G.823 − 2048 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 <τ≤ 0.2 46 τ0.2 <τ≤ 32 932 <τ≤ 64 0.28 τ64 <τ≤ 1 000 (Note) 18NOTE − For the asynchronous configuration (refer toFigure B.1), the maximum observation interval to be considered is 80 seconds.T1315370-99Observation Interval τ (sec)MRTIE (µsec)1001892.310.111010010000.050.2326410000.01Figure 1/G.823 − 2048 kbit/s interface output wander limit5.2.2 34 368 kbit/s interface output wander limitThe maximum level of wander that may exist at a 34 368 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 3. The resultant overall specification is illustrated in Figure 2.NOTE − 34 368 kbit/s signals can be framed in accordance with ITU-T Recommendation G.832.Table 3/G.823 − 34 368 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 < τ ≤ 0.073 14 τ 0.073 < τ ≤ 2.5 1 2.5 < τ ≤ 10 0.4 τ 10 < τ ≤ 804T1315380-99Observation Interval τ (sec)MRTIE (µsec)0.70.11101000.050.073 2.510800.0114Figure 2/G.823 − 34 368 kbit/s interface output wander limit5.2.3 139 264 kbit/s interface output wander limitThe maximum level of wander that may exist at a 139 264 kbit/s network interface, expressed in MRTIE, shall not exceed the limit given in Table 4. The resultant overall specification is illustrated in Figure 3.NOTE − 139 264 kbit/s signals can be framed in accordance with ITU-T Recommendation G.832.Table 4/G.823 − 139 264 kbit/s interface output wander limitObservation Intervalτ (sec) MRTIE requirement(µs)0.05 < τ ≤ 0.15 6.8 τ 0.15 < τ ≤ 2.5 1 2.5 < τ ≤ 10 0.4 τ 10 < τ ≤ 804T1315390-99Observation Interval τ (sec)MRTIE (µsec)1010.340.10.11101000.050.15 2.510800.0114Figure 3/G.823 − 139 264 kbit/s interface output wander limit6 Network limits for synchronization interfacesThe specification of network limits for synchronization interfaces is primarily intended to reflect the results of a theoretical analysis of the worst-case accumulation of jitter and wander in a synchronization network. These values then serve to specify tolerance requirements for synchronization equipment.It should, however, also be possible to verify through measurements in a real network that the jitter and wander at a particular interface does not exceed the specified limits. The location of the interface in the synchronization chain of that network determines what margin may be expected with reference to the network limits.As shown in Figure B.3, an SSU may receive its timing via SDH or PDH distribution. The network limit at the output of these distribution chains represents the amount of jitter and wander that an SSU may experience at its input. Since there is more jitter allowed at PDH interfaces than at SDH Synchronous Transport Module, level N (STM-N) interfaces, the network limit for the PDH distribution outputs represents the worst-case that the SSU should tolerate at its input.The jitter and wander tolerance of an SEC should be (at least) the amount of jitter and wander at the input of the last SEC of a synchronization chain. Since the contribution of the last SEC in the chain to the network limit at SEC outputs (that is the amount of jitter and wander that may be expected at the output of the last SEC of the chain) is small, the network limit at the SEC output interface can be used as the jitter and wander tolerance requirement for an SEC.6.1 Network limits for output jitter at synchronization interfacesThe maximum allowable high frequency noise components of a timing signal are specified by the network limits for jitter given in Table 5. These network limits are compatible with the minimum tolerance to jitter that clock equipment input ports are required to provide. The limits given in Table 5 shall be met for all operating conditions at 2048 kbit/s and 2048 kHz synchronization interfaces.Jitter as measured over a 60 second interval shall not exceed the specified limits, when using the specified measurement filters.The functional description for measuring output jitter at a digital interface is provided in ITU-T Recommendation O.172. Further requirements concerning the measurement of jitter are defined in 5.1.Table 5/G.823 − Maximum permissible jitter at synchronization interfacesOutput InterfaceMeasurementbandwidth,–3 dB frequencies (Hz)Peak-to-peak amplitude(UIpp)PRC 20 to 100 k 0.05SSU 20 to 100 k 0.05SEC 20 to 100 k 0.549 to 100 k 0.2PDH synchronization 20 to 100 k 1.518 k to 100 k 0.2NOTE − For 2048 kbit/s and 2048 kHz synchronization interfaces, UIpp refers tothe reciprocal of the clock frequency.6.2 Network limits for output wander at synchronization interfacesAt very low frequencies, synchronization networks are transparent to wander. Consequently, two signals received in the same node that derive their timing from the same source, but over different paths, may in the worst-case have opposite phase deviation. The minimum wander tolerance in the frequency range where relevant equipment is affected by the differential phase variation between two inputs is therefore higher than the network limit for absolute wander. The performance of a clock is only influenced by the phase variation that is experienced at the selected synchronization input. That is why the absolute network limits in the following subclauses can be used directly to specify wander tolerance of the SSU and SEC.The network limit requirements for TDEV are derived from simulation, taking into account the 18 µs wander budget and the requirements of ITU-T Recommendation G.822 (further information is provided in Annex A). However, large diurnal wander with a period of one day and sinusoidal characteristic may cause the TDEV network limit (at SSU, SEC or PDH interfaces) to be exceeded, even if the corresponding MTIE requirement is met. This is because the TDEV parameter does not strongly filter sinusoidal components of wander.。

封闭轮廓提取-概述说明以及解释

封闭轮廓提取-概述说明以及解释

封闭轮廓提取-概述说明以及解释1.引言1.1 概述轮廓提取是一种在计算机视觉和图像处理领域中常见的技术，它可以从图像或物体的边缘提取出封闭的边界线。

封闭轮廓提取是指将图像或物体的边缘线连接成一个封闭的形状，形成一个闭合的边界。

这项技术在许多领域都具有广泛的应用，包括目标检测与识别、图像分割、计算机辅助设计等。

封闭轮廓提取对于许多图像处理算法的前处理步骤至关重要。

通过提取出物体的封闭轮廓，可以将目标从背景中分离出来，进而实现对目标的进一步处理和分析。

例如，在目标检测与识别中，先提取出目标的封闭轮廓，然后再进行特征提取和分类器训练，有助于提高检测与识别的准确性和效率。

封闭轮廓提取方法和技术的研究也取得了显著进展。

传统的方法包括基于边缘检测、阈值分割、区域增长等算法，但这些方法存在一定的局限性，如对复杂背景的边缘提取效果不佳、对噪声敏感等。

近年来，随着计算机视觉和深度学习领域的发展，出现了基于深度学习的封闭轮廓提取方法，通过卷积神经网络等模型，能够更准确地提取出物体的封闭轮廓。

本文将在接下来的章节中详细介绍封闭轮廓提取的定义和背景，探讨封闭轮廓提取的意义以及介绍封闭轮廓提取的方法和技术。

最后，我们将对封闭轮廓提取的重要性进行总结，展望未来研究的发展方向，并给出本文的结论。

通过本文的阐述，读者将更加全面地了解封闭轮廓提取在图像处理中的重要性和应用前景。

1.2文章结构文章结构部分的内容如下：文章结构部分旨在介绍整篇文章的组织结构，帮助读者了解本文的内容安排和逻辑顺序。

本文的结构主要分为引言、正文和结论三个部分。

引言部分旨在引入封闭轮廓提取这个主题，并在概述中对封闭轮廓提取进行简要介绍。

接着介绍文章的目的，明确本文的研究目标和意义。

正文部分是本文的核心部分，主要分为三个小节。

首先，2.1节将定义并介绍轮廓提取的背景，包括其在计算机视觉和图像处理领域的应用以及其相关概念和技术。

其次，2.2节将重点探讨封闭轮廓提取的意义，包括其在实际应用中的重要性和潜在的挑战。