Automatic verification of deontic properties of multi-agent systems
Synopsys Formality EC Solution说明书

DATASHEETOverview Formality ® is an equivalence-checking (EC) solution that uses formal, static techniques to determine if two versions of a design are functionally equivalent.Formality delivers capabilities for ECO assistance and advanced debugging to help guide the user in implementing and verifying ECOs. These capabilities significantly shorten the ECO implementation cycle.The size and complexity of today’s designs, coupled with the challenges of meeting timing, area, power and schedule, requires that the newest, most advanced synthesis optimizations be fully verifiable.Formality supports all of the out-of- the-box Design Compiler ® and Fusion Compiler™ optimizations and so provides the highest quality of results that are fully verifiable.Formality supports verification of power-up and power-down states, multi-voltage, multi- supply and clock gated designs.Formality’s easy-to-use, flow-based graphical user interface and auto-setup mode helps even new users successfully complete verification in the shortest possible time.Figure 1: Formality equivalence checking solutionIndependent formalverification of DesignCompiler and FusionCompiler synthesisresults, with built-in intelligencedelivering the highestverifiable QoRFormality Equivalence Checking and Interactive ECOKey Benefits• Perfect companion to Design Compiler and Fusion Compiler—supports all default optimizations• Intuitive flow-based graphical user interface• Verifies low-power designs including power-up and power-down states• ECO implementation assistance, fast verification of the ECO, and advanced debugging• Auto setup mode reduces “false failures” caused by incorrect or missing setup information• Multicore verification boosts performance• Automated guidance boosts completion with Design Compiler and Fusion Compiler• Verifies full-custom and memory designs when including ESP technologyFormalityThe Most Comprehensive Equivalence Checking SolutionFormality delivers superior completion on designs compiled with Design Compiler or Fusion Compiler. Design Compiler is the industry leading family of RTL Synthesis solutions. Fusion Compiler is the next generation RTL-to-GDSII implementation system architected to address the complexities of advanced process node design. Designers no longer need to disable the powerful optimizations available with Design Compiler or Fusion Compiler to get equivalence checking to pass. Design Compiler/Fusion Compiler combined with Formality delivers maximum quality of results (QoR) that are fully verifiable.Easy to Use with Auto-setup modeFormality’s auto-setup mode simplifies verification by reducing false failures caused by incorrect or missing setup information. Auto-setup applies setup information in Formality to match the assumptions made by Design Compiler or Fusion Compiler, including naming styles, unused pins, test inputs and clock gating.Critical files such as RTL, netlists and libraries are automatically located. All auto-setup information is listed in a summary report.Guided SetupFormality can account for synthesis optimizations using a guided setup file automatically generated by Design Compiler or Fusion Compiler. Guided setup includes information about name changes, register optimizations, multiplier architectures and many other transformations that may occur during synthesis. This correct-by-construction information improves performance and first-pass completion by utilizing the most efficient algorithms during matching and verification.Formality-guided setup is a standard, documented format that removes unpredictability found in tools relying on log file parsing.Independent VerificationEvery aspect of a guided setup flow is either implicitly or explicitly verified, and all content is available for inspection in an ASCII file.Figure 2: Automatic cone pruning improves schematic readability when debuggingHier-IQ TechnologyPatented Hier-IQ technology provides the performance benefits of hierarchical verification with flat verification’s out-of- the-box usability.Error-ID TechnologyError-ID identifies the exact logic causing real functional differences between two design representations. Error-ID can isolate and report several logic differences when multiple discrepancies exist. Error-ID will also present alternative logic that can be changed to correct a given functional difference; this flexibility allows the designer to select the change that is easiest to implement.Failing Pattern Display WindowAll failing input patterns can be viewed in a familiar spreadsheet-like format. The failing pattern window is an ideal way to quickly identify trends indicating the cause of a failing verification or improper setup.Figure 3: Problem areas can be easy identified by visual inspection of the Failing Pattern WindowPower-aware VerificationFormality is fully compatible with Power Compiler™ and verifies power-up and power-down states, multi-voltage, multi-supply and clock gated designs.When a reference design block is powered up, Formality verifies functionality. If the implementation design powers up differently, failing points will occur.Formality functionally verifies that the implementation powers down when the reference powers down and will detectfunctional states where the implementation does not power down as expected. The valid power states are defined in the power state table (PST).Power intent is supplied to Formality through IEEE 1801 Unified Power Format (UPF).Figure 4: Power connectivity is easy to see and debug from the schematic viewAccelerated Time to ResultsFormality’s performance is enhanced with multicore verification. This Formality capability allows verification of the design using up to four cores simultaneously to reduce verification time.Other Time-Saving FeaturesFormality’s Hierarchical Scripting provides a method to investigate sub-blocks without additional setup and is ideal for isolating problems and verifying fixes.The Source Browser opens RTL and netlist source files to highlight occurrences of a selected instance. This can help users correlate between the RTL and gate-level design versions.Error Region Correlation provides a quick, visual identification of the logic from one design that correspond to the errors isolated by Error-ID within the other.Command Line Editing allows you to take advantage of history and common text editor commands when working from Formality’s command line.Interactive ECOKey BenefitsProvides GUI-driven ECO implementation assistance, fast ECO verification, and advanced debugging. Formality guides the user through the implementation of ECOs, and then quickly verifies only the changed logic.Formality Interactive ECO FlowFormality uses the ECO RTL and an unmodified netlist. Guided GUI driven changes are made to the netlist. Once the ECO has been implemented, a quick verification is run on only the affected logic cones, eliminating the need for a full verification run on the design to verify that the ECO was implemented correctly.Once all ECO’s are implemented and fully verified, a list of IC Compiler™ commands is generated to assist in implementing the physical changes to the design.ECO GuidanceFormality highlights equivalent nets between the reference and implementation designs, and nets that have lost their equivalence due to the ECO changes in the reference. This helps the designer quickly identify where the change should be made in the implementation.Implementing the ECOEditing commands in Formality are used to modify the netlist in-place using the GUI.Rapid ECO VerificationFormality can identify and verify just the portion of the design affected by the ECO. This ensures that the ECO was implemented correctly. If the ECO verification fails, the ECO can be interactively “undone” and new edits can be made again. Once the partial verification passes, the changes are committed. This partial verification eliminates having to verify the entire design to assure that the ECO was implemented correctly, dramatically reducing the total time required to implement and verify the ECO.Figure 5: Equivalent net is highlighted between Reference design (left) and Implementation design (right)Figure 6: On a completed ECO, the schematic shows the nets affected by ECO in yellow, and the new component and net in orangeFigure 7: Formality transcript shows a successful partial verification of the portion of the design that was affected by the ECOInterface with IC Compiler IIOnce the ECO’s are implemented and verified, a final complete verification run is performed to assure that the ECO RTL and the ECO netlist are functionally equivalent.Formality produces IC Compiler II compatible ECO command file, easing the implementation in the physical design.Advanced DebuggingFormality incorporates advanced debugging capabilities that help the designer identify and debug verifications that do not pass. The designer can find compare points, equivalences (and inverted-equivalences) between reference and implementation designs, perform “what if” analysis by interactively modifying the designs, and verify equivalence between two (or multiple) points.Transistor VerificationESP combines with Formality to offer fast verification of custom circuits, embedded memories and complex I/Os. ESP technology directly reads existing SPICE and behavioral RTL models and does not require restrictive mapping or translation.Input Formats• Synopsys DC, DDC, Milkyway™• IEEE 1800 SystemVerilog• Verilog-95, Verilog-2001• VHDL-87, VHDL-93• IEEE 1801 Unified Power Format (UPF)Guided Setup Formats• Synopsys V-SDC• Formality Guide Files (SVF)Platform Support• Linux Suse, Red Hat and Enterprise• SPARC SolarisFor more information about Synopsys products, support services or training, visit us on the web at: , contact your local sales representative or call 650.584.5000.©2019 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks isavailable at /copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.。
DoD UII Guide V2.0 美国国防部唯一标识符导则

Department of Defense Guide to UniquelyIdentifying ItemsAssuring Valuation, Accountability and Control of Government PropertyVersion 2.0October 1, 2008Office of the Deputy Under Secretary of Defense(Acquisition, Technology & Logistics)PrefaceThis Version 2.0 of the Department of Defense Guide to UniquelyIdentifying Items replaces all previous versions.Summary of Changes from Version 1.6 (Dated June 1, 2006) toVersion 2.0:a. Content changes were incorporated in the basic document:• To include Department of Defense (DoD) Directive8320.03, Unique Identification (UID) Standards for a Net-Centric Department of Defense, March 23, 2007, whichprovides for UID data standards development andimplementation of the Department’s UID strategy.• To include DoD Instruction 8320.04, Item UniqueIdentification (IUID) Standards for Tangible PersonalProperty, June 16, 2008, which provides for IUID policyimplementation.• To update terminology and references associated with theDoD Business Enterprise Architecture.• To include program manager and item manager roles in theitem management discussion.• To incorporate changes in DoDI 5000.64, Defense PropertyAccountability, November 2, 2006.• To clarify applicability of DFARS 252.211-7003 to newequipment, major modifications, and reprocurements ofequipment and spares.• To clarify that alternative implementation is permittedprovided that the acquired items are marked and registeredno later than 30 days after receipt.• To emphasize that embedded items that require IUID mustbe listed in the contract.• To clarify the distinction among the concatenated UII, theUII data set, and the mark or data string containing the UIIdata set.• To emphasize that Construct 2 contains an original partnumber or, when serialization is within a lot or batch,contains a lot or batch number in lieu of the original part number.• To provide additional guidance on the use of data qualifiers for single data elements that are sufficient to derive UIIs. • To further clarify that the Global Returnable Asset Identifier (GRAI) must contain a unique serial number for DoD recognized IUID equivalent application.• To emphasize the responsibility of the entity in the enterprise identifier to ensure the uniqueness of the UII at the time of its assignment and to emphasize the continuing nature of the responsibility.• To further emphasize that the enterprise identifier in the UII is the entity that is responsible for compliance with the UII rules. An entity cannot commit another entity to that responsibility without authority. The fundamental principle is: Never use another entity’s enterprise identifier in the UII without permission or direction from the competent authority for that enterprise identifier.• To clarify and expand references to the enterprise identifier NCAGE.• To remove redundant descriptions of UII Constructs #1 and #2.• To remove guidance language related to evaluating items meeting the mission essential and controlled inventory criteria for possible exclusion. This guidance was inconsistent with IUID policy language associated specifically with mission essential and controlled inventory. Related annotations in Figure 2 and Figure 3 were removed.• To clarify that the parent item of an embedded item may be chosen at any appropriate level of configuration above the level of the embedded item.• To clarify that Sets, Kits and Outfits (SKO) may qualify for IUID based on the criteria applied to delivered items and that individual items in the SKO may qualify for IUID as embedded items in the parent SKO.• To update the reference for the Coded Representation of the North American Telecommunications Industry Manufacturers, Suppliers, and Related Service Companies Number from ANSI T1.220 to ATIS-0322000. Table 3 was revised accordingly.• To clarify that the issuing agency code (IAC) for the GS1 Company Prefix need not be derived because it is containedin each GS1 Company Prefix. The IAC should not berepeated when forming the concatenated UII.• To clarify that the IAC for the data qualifiers 3V, 18V, 25S, EUC and UID need not be derived because it is containedin each data element. The IAC should not be repeatedwhen forming the concatenated UII.• To provide a method for identifying a traceability number that is not part of the UII. Table 4 was revised accordingly.• To incorporate marking quality provisions ofMIL-STD-130N in Figure 5.• To clarify discussion of when to mark items.b. Appendix A definitions were updated and edited forcompatibility with original part number and lot or batch number usage, and other UII clarifications and distinctions as emphasized in the basic document.c. Appendix B references were updated.d. Appendix C was updated to version 4.0 of the Business Ruleswith content changes incorporated:• To emphasize that both classified and unclassified contracts require IUID.• To clarify that the concatenated UII may be derived from a single data element when using certain data qualifiers.• To require that the marking of component data elements in addition to the concatenated UII be selected and specifiedexplicitly.• To clarify that an encoded UII data string may contain the component data elements in any order. The ordering of theelements into a valid UII is done after the decoding of thesymbol.• To emphasize that the enterprise identifier in the UII is the entity that is responsible for compliance with the UII rulesand that an entity cannot use another entity’s enterpriseidentifier in the UII without permission or direction fromthe competent authority for that enterprise identifier.• To clarify that original part numbers and lot or batch numbers are mutually exclusive in the UII. In order toavoid ambiguity, only one of those three types of original numbers may appear in the mark.• To clarify that AIT devices determine the UII Construct from the specific set of data qualifiers.• To allow the UII Construct #2 requirement to maintain the original part number or lot or batch number on the item for the life of the item to be satisfied by maintaining the data element containing the original part number or lot or batch number on the item for the life of the item (e.g., TEI UID ). • To emphasize that added data elements must not introduce ambiguity in the concatenation of the UII and must conform to all other business rules.• To allow enterprise identifiers as added data elements provided that any additional enterprise identifier does not introduce ambiguity in the concatenation of the UII.• To require that single data elements that are sufficient to derive UIIs (i.e., 18S, 25S, UID , UST , USN , and DoD recognized IUID equivalents) always be interpreted as the UII regardless of any apparent ambiguity introduced by additional data elements in the symbol.• To clarify that ISO/IEC 15434 syntax is required for the Data Matrix ECC 200 symbol.• To require that the concatenated UII not exceed 50 characters in length. Maximum field lengths for individual data elements are not changed, however the overall length limitation must be met.• To prescribe the use of dashes(-) and slashes(/) in MH10.8.2 Data Identifiers (DIs) as significant characters for part numbers, lot or batch numbers, and serial numbers, and in DIs that are composed from these numbers (i.e., S, 18S, 25S, 1P, 30P and 30T).• To prohibit the use of dashes and slashes as separators between component parts in a single data element that is formed from component parts.• To caution users on practical limitations of implementing free text formats.• To emphasize that prior to derivation of UIIs from backup information the existence of a UII shall be checked by querying the IUID Registry for confirmation of any identifiable information already marked on the item.• To clarify that existing databases may use a combination of the UII component data elements to retrieve data records.• To prohibit assigning more than one UII to an item.• To clarify that Business Rules for Items in Operational Use or in Inventory apply in addition to Business Rules #1-#27.• To clarify that the enterprise identifier used in marking a legacy item must be the enterprise identifier of the entityassigning and registering the UII of the item.• To clarify that the choice to use or not use the existing part number and/or existing serial number of a legacy item aspart of the UII under their EID is the responsibility of theentity assigning the UII as is the uniqueness of the resultingUII.• To require that the original equipment manufacturer (OEM) enterprise identifier and manufacturer assigned serialnumber, if marked on the item and not a part of the UII, beregistered.• To clarify that an item that is not sufficiently identifiable to confirm serviceability should not be assigned a UII.• To clarify that support contracts shall specify the extent to which IUID Business Rules for items in operational use orin inventory apply.• To clarify that IUID is required for Government property in the possession of a contractor.• To clarify that Business Rules for Items in Operational Use or in Inventory apply in addition to Business Rules #1-#32.e. Appendix D was updated with content changes incorporated:• To replace interim format indicator “DD” with the newly assigned format indicator “12” for use with Text ElementIdentifiers (TEIs). Items that have been marked with theformat indicator “DD” do not have to be re-marked butfurther use of “DD” is not permitted.• To update Table 5 to remove Application Identifiers (AIs)95 and 10 which are no longer used to construct UIIs.These Application Identifiers may continue to be used asadditional data elements. Data qualifiers for single dataelements that are sufficient to derive UIIs were reorderedand IUID equivalents were grouped together. The DI 30Twas introduced to provide a method for identifying atraceability number that is not part of the UII.• To clarify the distinction among TEIs LOT , LTN and BII . • To expand the AI 8004 Global Individual Asset Identifier(GIAI) to include new GS1 procedures to convert a serialized Global Trade Identification Number (GTIN™) toa GIAI.• To clarify the distinction between DIs 1P and 30P.• To clarify the distinction between DIs 1T and 30T.• To replace Figure 6 with new figures—Figure 6, Figure 7 and Figure 8. The new figures contain the required data qualifiers and the resultant concatenated UII for the UII constructs and the IUID equivalents. A separate figure is provided for each format indicator.• To replace Table 6 and the accompanying examples for Construct #1 using DIs. The component data elements were eliminated from the previous examples. Selected component data elements are required when they are specified explicitly.• To update Table 7 and the accompanying example for Construct #2 using DIs. New Table 7 uses the previous example for serialization within the original part number. • To insert new Table 8 with a new example for serialization within the lot number.• To update Table 9 and accompanying example for constructing the UII from the component elements of a serialized Global Trade Identification Number (GTIN™). • To update and move Table 8 (renumbered new Table 10) and to clarify the accompanying example using the AI for the IUID equivalent GIAI. The example uses a GIAI using the individual asset reference number.• To insert new Table 11 and the accompanying example introducing new GS1 procedures to convert a serialized Global Trade Identification Number (GTIN™) to a GIAI. • To incorporate the replacement of the interim format indicator “DD” by format indicator “12” in the appropriate tables and figures. Items that have been marked with the format indicator “DD” do not have to be re-marked but further use of “DD” is not permitted.• To update the examples for Construct #1 and Construct #2 using TEIs and the new format indicator “12”. The example for serialization within original part number was annotated to clarify that LOT , LTN or BII should besubstituted for PNO for serialization within the lot or batchnumber, as appropriate.• To renumber Tables 10, 11 and 12 to Tables 12, 13 and 14 respectively.f. Appendix E was updated and the unused CLEI was deleted.g. Changes for compatibility with the changes reflected above, aswell as various typographical, grammatical and format corrections, were made throughout.Table of Contents Preface (ii)Chapter 1: The Environment (1)The Government Property Management Challenge (1)The Definition of Items (2)The Objectives (2)Item Management (3)The Players (3)Processes, Activities and Actions (5)Chapter 2: The Need to Uniquely Identify Items (7)Differentiating Items Throughout the Supply Chain (7)Accounting for Acquired Items (7)Contractor-acquired Property on Cost-Reimbursement Type Contracts (8)Establishing Item Acquisition Cost (8)Using Contract Line Items (8)Valuation of Items for the IUID Registry (10)Chapter 3: Requirements for Item Unique Identification (12)What is an Item? (12)Deciding What Items are to be Identified as Unique (12)Items Delivered Under Contracts and Legacy Items in Inventory and Operational Use (12)Unit Acquisition Cost Threshold (14)IUID of Items Below the $5,000 Threshold (14)DoD Serially Managed (14)Mission Essential (15)Controlled Inventory (15)Other Compelling Reasons for Items Below the $5,000 Threshold (16)IUID of Embedded Items Regardless of Value (16)IUID of Sets, Kits and Outfits (16)Legacy Items in Operational Use and Inventory (17)Chapter 4: Determining Uniqueness of Items (19)Defining the Data Elements for the Unique Item Identifier (19)What is the Unique Item Identifier (UII)? (19)The Notion of an Enterprise (19)Unique Identification of Items (20)Serialization Within the Enterprise Identifier (20)Serialization Within the Part, Lot or Batch Number (21)Issuing Agency Codes for Use in Item Unique Identification (21)Including Unique Item Identifier (UII) Data Elements on an Item (22)Derivation of the Concatenated UII (22)Concatenated UII Derivation Process (24)Deciding Where to Place Data Elements for Item Unique Identification on Items..25 DoD Recognized IUID Equivalents (26)Compliant Unique Item Identifier (26)Considerations for Suppliers (26)Deciding When to Place IUID Data Elements on the Item (28)Use of the Unique Item Identifiers in Automated Information Systems (29)Roles and Responsibilities for Property Records (30)Appendix A - Definitions (31)Key Definitions (31)Appendix B - Where Does the Guidance Exist Today? (41)Appendix C - Business Rules (Version 4.0) (42)What are Business Rules? (42)IUID Business Rules (42)Contracts and Administration (43)UII Construction and Physical Marking (43)Items Considered Part of a New Solicitation (43)Items in Operational Use or in Inventory (48)Items Considered Tangible Personal Property Owned by the Government in thePossession of a Contractor that Have Not Been Previously Marked (49)Appendix D - The Mechanics of Item Unique Identification (50)Structuring the Data Elements for Item Unique Identification (50)Semantics (50)Syntax (52)Examples of Semantics and Syntax Constructions for Item Unique Identification (57)Using ANS MH 10 Data Identifiers (57)Using GS1 Application Identifiers (62)Historic Use of Text Element Identifiers (67)The Collaborative AIT Solution (67)Using Text Element Identifiers (68)Appendix E - Glossary of Terms (73)Chapter 1The EnvironmentT HE G OVERNMENT P ROPERTY M ANAGEMENTC HALLENGEThe Government Accountability Office (GAO) aptly describes thechallenge faced by today’s managers of Federal Government property:“GAO and other auditors have repeatedly found that the federalgovernment lacks complete and reliable information for reported inventoryand other property and equipment, and can not determine that all assets arereported, verify the existence of inventory, or substantiate the amount ofreported inventory and property. These longstanding problems withvisibility and accountability are a major impediment to the federalgovernment achieving the goals of legislation for financial reporting andaccountability. Further, the lack of reliable information impairs thegovernment’s ability to (1) know the quantity, location, condition, andvalue of assets it owns, (2) safeguard its assets from physical deterioration,theft, loss, or mismanagement, (3) prevent unnecessary storage andmaintenance costs or purchase of assets already on hand, and (4)determine the full costs of government programs that use these assets.Consequently, the risk is high that the Congress, managers of federalagencies, and other decision makers are not receiving accurate informationfor making informed decisions about future funding, oversight of federalprograms involving inventory, and operational readiness”.1 Further, theCongress has demanded greater fiscal accountability from managers offederal government property.21 GAO-02-447G, Executive Guide, Best Practices in Achieving Consistent, Accurate Physical Counts of Inventory and Related Property, March 2002, page 6.2 Ibid., page 5: The GAO observes that “In the 1990s, the Congress passed the Chief Financial Officers Act of 1990 and subsequent related legislation, the Government Management Reform Act of 1994, the Government Performance and Results Act of 1993, and the Federal Financial Management Improvement Act of 1996. The intent of these acts is to (1) improve financial management, (2) promote accountability and reduce costs, and (3) emphasize results-oriented management. For the government’s major departments and agencies, these laws (1) established chief financial officer positions, (2) required annual audited financial statements, and (3) set expectations for agencies to develop and deploy modern financial management systems, produce sound cost and operating performance information, and design results-oriented reports on the government’s financial position by integrating budget, accounting, and program information. Federal departments and agencies work hard to address the requirements of these laws but are challenged to provide useful, reliable, and timely inventory data, which is still not available for daily management needs.”T HE D EFINITION OF I TEMSFor the purposes of this guide, an item is a single hardware article or asingle unit formed by a grouping of subassemblies, components, orconstituent parts.3T HE O BJECTIVESDepartment of Defense (DoD) Directive 8320.03, Unique Identification(UID) Standards for a Net-Centric Department of Defense, March 23,2007, provides for UID data standards development and implementationof the Department’s UID strategy. It establishes policy and prescribes thecriteria and responsibilities for creation, maintenance, and disseminationof UID data standards for discrete entities to enable on-demandinformation in a net-centric environment, which is an essential element inthe accountability, control, and management of DoD assets and resources.It also establishes policy and assigns responsibilities for the establishmentof the Department’s integrated enterprise-wide UID strategy and for thedevelopment, management, and use of unique identifiers and theirassociated authoritative data sources in a manner that precludesredundancy. Item unique identification (IUID) is the fundamental elementof the Department’s strategy for the management of its tangible items ofpersonal property. A corresponding DoD Instruction 8320.04, ItemUnique Identification (IUID) Standards for Tangible Personal Property,has been issued for policy implementation.DoD Instruction 5000.64, Defense Property Accountability, requires thataccountability records be established for all property (property, plant andequipment) with a unit acquisition cost of $5,000 or more, and items thatare sensitive or classified, or items furnished to third parties, regardless ofacquisition cost. Property records and/or systems are to provide acomplete trail of all transactions, suitable for audit.4DoD 4140.1-R, DoD Supply Chain Material Management Regulation,requires accountability and inventory control requirements for all propertyand materiel received in the wholesale supply system.A key component of effective property management is to use sound,modern business practices.3 DFARS 252.211-7003(a).4 Property accountability records and systems shall contain the data elements specified in DoD Instruction 5000.64, paragraph 6.6, including part number, cost, national stock number, unique item identifier (UII) or DoD recognized item unique identification (IUID) equivalent, and other data elements listed.In terms of achieving the desirable end state of integrated management ofitems, the collective DoD goal shared by all functional processes involvedin property management is to uniquely identify items, while relying to themaximum extent possible on international standards and commercial itemmarkings and not imposing unique Government requirements. Uniqueidentification of items will help achieve:• Integration of item data across the Department of Defense(hereafter referred to as the Department), and Federal andindustry asset management systems, as envisioned by the DoDBusiness Enterprise Architecture (BEA)5, to include improveddata quality and global interoperability and rationalization ofsystems and infrastructure.• Improved item management and accountability.• Improved asset visibility and life cycle management.• Clean audit opinions on item portions6 of DoD financialstatements.I TEM M ANAGEMENTThe acquisition, production, maintenance, storage, and distribution ofitems require complete and accurate asset records to be effective, and toensure mission readiness. Such records are also necessary for operationalefficiency and improved visibility, as well as for sound financialmanagement. Physical controls and accountability over items reduce therisk of (1) undetected theft and loss, (2) unexpected shortages of criticalitems, and (3) unnecessary purchases of items already on hand.T HE P LAYERSProgram managers and item managers lead the coordinated efforts ofvarious stakeholders. The principal functional stakeholders in itemmanagement are Engineering Management; Acquisition Management;Property, Plant and Equipment Accountability; Logistics Management andAccountability, and Financial Management. Asset visibility is crosscuttingto these five functions. Their interests involve the following:5 On March 15, 2007, the DoD Business Transformation Agency (BTA) released the Business Enterprise Architecture (BEA 4.1), which defines the processes, roles, data structures, information flows, business rules, and standards required to guide improvements in the Core Business Missions (CBMs) of the Department.6 These financial statement portions are (1) Property, Plant and Equipment and (2) Operating Materials and Supplies.Engineering Management. DoD Directive 5000.1, DefenseAcquisition System, requires that acquisition programs be managedthrough the application of a systems engineering approach that optimizestotal system performance and minimizes total ownership costs. A modular,open-systems approach is employed, where feasible. For purposes of itemmanagement, engineering plays a crucial role in the documentation oftechnical data that defines items and the configuration management ofthese items throughout their useful life.Acquisition Management. The Federal AcquisitionRegulation (FAR) Part 45, Government Property, prescribes policies forfurnishing Government property to contractors including the use,maintenance, management and reporting of Government-furnishedproperty and contractor-acquired property, and for the return, delivery, ordisposal of Government-furnished property and contractor-acquiredproperty.Property, Plant and Equipment Accountability.DoD Instruction 5000.647 provides a comprehensive framework for DoDproperty accountability policies, procedures, and practices; and assistsDoD property managers, accounting and financial officers, and otherofficials in understanding their roles and responsibilities relating toproperty accountability. It establishes accountability policy for property,plant, and equipment (PP&E); and contains concepts useful for assetmanagement throughout the Department, particularly for property in thepossession of individual military units and end-users. It excludes propertyand materiel for which accountability and inventory control requirementsare prescribed in DoD 4140.1-R and DoD 4000.25-2-M.8Logistics Management and Accountability. DoDDirective 4140.1, Materiel Management Policy, specifies policies formateriel management. It is the Department’s policy that:• Materiel management is responsive to customer requirementsduring peacetime and war.• Acquisition, transportation, storage, and maintenance costs areconsidered in materiel management decisions.7 DoDI 5000.64 integrates the broad requirements of the Federal Property and Administrative Services Actof 1949, as amended (Act of 30 June 1949, 63 Stat. 372), and the Chief Financial Officers (CFO) Act of 1990 into an overarching property accountability policy for property, plant and equipment. This instruction complements the accounting and financial reporting requirements contained in DoD 7000.14-R.8 Military Standard Transaction Reporting and Accounting Procedures (MILSTRAP).• Standard data systems are used to implement materielmanagement functions.• The secondary item inventory is sized to minimize theDepartment's investment while providing the inventory neededto support peacetime and war requirements• Materiel control and asset visibility are maintained for thesecondary item inventory.DoD 4000.25-M, Defense Logistics Management System (DLMS)Manual, prescribes logistics management policy, responsibilities,procedures, rules, and electronic data communications standards for theconduct of logistics operations in the functional areas of supply,transportation, acquisition (contract administration), maintenance, andfinance.9Financial Management. DoD Instruction 7000.14, DefenseFinancial Management Regulation, specifies that all DoD Componentsshall use a single DoD-wide financial management regulation foraccounting, budgeting, finance, and financial management education andtraining. That regulation is DoD 7000.14-R. It directs financialmanagement requirements, systems, and functions for all appropriated,non-appropriated, working capital, revolving, and trust fund activities. Inaddition, it directs statutory and regulatory financial reportingrequirements.Joint Total Asset Visibility. Joint total asset visibility is thecapability that provides Combatant Commanders, the Military Services,and the Defense Agencies with timely and accurate information on thelocation; movement; status; and identity of units, personnel, equipment,and supplies.10P ROCESSES, A CTIVITIES AND A CTIONSItem management involves many functional processes, activities andactions, all focused on operations involving items. These operations mustbe integrated and flow smoothly so that the needs of warfighters for items9The DLMS is a system governing logistics functional business management standards and practices rather than an automated information system.10 “In every troop deployment this century, DoD has been plagued by a major difficulty—the inability to see assets as they flow into a theater and are in storage. This situation has led to direct and significant degradation in operational readiness. When assets in the pipeline are not visible, they are difficult to manage. Property is lost, customers submit duplicate requisitions, superfluous materiel chokes the transportation system, and the cycle continues. Assets at the retail level that are not visible and, therefore, not available for redistribution, further compound the degradation of operational readiness.” Joint Total Asset Visibility Strategic Plan, January 1999, Joint Total Asset Visibility Office, DoD.。
欧盟工艺验证报告(中英文翻译)

VALIDATION REPORT APPROVAL验证报告批准
Activity 活动
Prepared By 制
定
Reviewed By 审
核
Name 姓名 PRAKASH.K.C
AMARESH.C
Designation 职务
Executive主 管
Department部
Batch No批号. 907001 (Lot - I) (10 Minutes)
Sample Location
样品位置
Top 顶部
Middle Left 中左
Middle 中部
Middle Right 中右
Bottom 底部
A.R.NO.: BPV 90066
Mean 平均
RSD %
Assay in mg
PROCESS VALIDATION SUMMARY REPORT 工艺验证总结报告
FOR MANUFACTURING PROCESS OF
Paracetamol tablets 500 mg 对乙酰氨基酚500mg片生产工艺
Product
BAFNA PHARMACEUTICALS LIMTED PROCESS VALIDATION SUMMARY REPORT
PAGE NO. 1 2 3 4 4 4
5-6 7
8 - 10 11 - 14 15 - 24 25 - 26 27 - 28
29 30 – 33
34 35
NO.OF PAGES 1 1 1 1 1 1 2 1 3 4 10 2 2 1 4 1 1
Product
BAFNA PHARMACEUTICALS LIMTED PROCESS VALIDATION SUMMARY REPORT
5_Why_Root_Cause_Corrective_Actions

However, the 8D is not effective for:
• Non-recurring problems or problems which can be solved quickly by individual effort. • Problems with known root causes. • Making a decision between different alternatives. • Problems where the simplest and most obvious solution is likely to be the best or adequate solution.
© 2013 Brooks Automation, Inc. • Proprietary Information
What are the 8Ds?
Pre 8D: Once a problem has been recognized, the 8 disciplines used to solve it are: 1) Team Formation 2) Problem Description 3) Implementing Interim Containment Actions 4) Defining Problem Root Causes 5) Developing Permanent Corrective Actions 6) Implementing Permanent Corrective Actions 7) Preventing Reoccurrences 8) Recognizing and Congratulating the Team
© 2013 Brooks Automation, Inc. • Proprietary Information
再验证方案用英文

Verification Program: A comprehensive guide IntroductionIn today’s competitive digital landscape, it is essential to ensure the reliability and accuracy of software systems. Verification programs play a crucial role in validating the functionality and performance of various software applications. This document aims to provide a comprehensive guide to verification program design, emphasizing the utilization of English for better understanding and collaboration among international teams.Table of Contents1.What is Verification?2.Why is Verification Important?3.Types of Verification4.Key Components of a Verification Program–Test Planning–Test Design–Test Execution–Test Reporting5.Verification Program Workflow6.Challenges in Verification7.Best Practices for Successful Verification8.Conclusion1. What is Verification?Verification is the process of evaluating software systems to determine whether they comply with the specified requirements. It involves conducting systematic tests, inspections, and analyses to ensure that the software behaves as intended and meets the customer’s expectations.2. Why is Verification Important?Effective verification is critical to the success of software systems. It helps identify defects, ensures compliance with regulations and standards, and enhances the overall quality of the software. By thoroughly testing and validating the software, potential issues and risks can be mitigated, resulting in increased user satisfaction and reduced development costs.3. Types of VerificationThere are various types of verification techniques employed in software development. Some common types include:•Static Testing: This technique involves analyzing the software code or documentation without executing it. It includes techniques like code reviews, inspections, and walkthroughs.•Dynamic Testing: Unlike static testing, dynamic testing involves the execution of software to test its behavior. This includes techniques such as unit testing, integration testing, system testing, and acceptance testing.•Model-based Testing: This approach involves creating a model of the system and generating test scenarios based on the model.•Performance Testing: Performance testing focuses on evaluating system performance under different load conditions to identify performance bottlenecks and ensure optimal performance.4. Key Components of a Verification ProgramTest PlanningTest planning involves defining the objectives, scope, and resources required for the verification process. It includes tasks such as identifying test scenarios, creating test plans, and allocating resources.Test DesignTest design encompasses the creation of test cases and test scenarios based on the specified requirements. It involves defining inputs, expected results, and test execution steps.Test ExecutionTest execution involves running the test cases and scenarios on the software system and validating the actual results against the expected results. It includes tasks like test environment setup, test data generation, and test execution.Test ReportingTest reporting is the process of documenting and communicating the results of the verification process. It includes generating test reports, defect reports, and providing recommendations for further improvement.5. Verification Program WorkflowA typical verification program follows the following workflow:1.Define Verification Objectives: Clearly define the objectives andgoals of the verification program.2.Identify Verification Scope: Determine the scope of the verificationprogram, including the software modules and functionalities to be tested.3.Plan Verification Activities: Develop a detailed test plan, includingtest scenarios, test cases, and resource allocation.4.Execute Verification Tests: Execute the test cases and scenarios,ensuring that each step is documented and executed as planned.5.Analyze Test Results: Analyze the test results and identify anydeviations from expected outcomes.6.Report and Document: Generate test reports, defect reports, anddocumentation that summarize the results and findings.7.Perform Root Cause Analysis: Investigate the root causes of anydefects or issues encountered during the verification process.8.Iterate and Improve: Incorporate lessons learned from theverification process and implement necessary improvements for future cycles.6. Challenges in VerificationWhile verification plays a crucial role in software development, several challenges need to be addressed:•Complexity: As software systems become more complex, verification becomes more challenging, as it involves testing various functionalities andcomponents.•Time and Resource Constraints: Limited time and resources can impede the thoroughness of the verification process.•Requirement Changes: Changes in project requirements can affect the scope and planning of the verification program.•Lack of Standardization: A lack of standardized verification practices can hinder effective collaboration among international teams.7. Best Practices for Successful VerificationTo overcome the challenges and ensure successful verification, developers can follow these best practices:•Early Verification: Start the verification process as early as possible, even during the software requirements gathering phase.•Clearly Defined Requirements: Ensure that requirements are well-documented and clearly understood by all stakeholders.•Utilize Test Automation: Automation can improve the efficiency and effectiveness of the verification process.•Collaboration and Communication: Foster effective communication and collaboration among team members to exchange ideas and share insights.•Standardized Practices: Establish standardized verification practices across teams to ensure consistency and facilitate collaboration.ConclusionVerification programs are essential for the successful development and deployment of software systems. By following this comprehensive guide, software developers can design and implement effective verification programs that minimize defects, meet customer expectations, and enhance overall software quality. Emphasizing the use of English is crucial to facilitate collaboration among international teams and ensure clarity in communication.。
Probabilistic model checking of an anonymity system

Probabilistic Model Checking ofan Anonymity SystemVitaly ShmatikovSRI International333Ravenswood AvenueMenlo Park,CA94025U.S.A.shmat@AbstractWe use the probabilistic model checker PRISM to analyze the Crowds system for anonymous Web browsing.This case study demonstrates howprobabilistic model checking techniques can be used to formally analyze se-curity properties of a peer-to-peer group communication system based onrandom message routing among members.The behavior of group mem-bers and the adversary is modeled as a discrete-time Markov chain,and thedesired security properties are expressed as PCTL formulas.The PRISMmodel checker is used to perform automated analysis of the system and ver-ify anonymity guarantees it provides.Our main result is a demonstration ofhow certain forms of probabilistic anonymity degrade when group size in-creases or random routing paths are rebuilt,assuming that the corrupt groupmembers are able to identify and/or correlate multiple routing paths originat-ing from the same sender.1IntroductionFormal analysis of security protocols is a well-establishedfield.Model checking and theorem proving techniques[Low96,MMS97,Pau98,CJM00]have been ex-tensively used to analyze secrecy,authentication and other security properties ofprotocols and systems that employ cryptographic primitives such as public-key en-cryption,digital signatures,etc.Typically,the protocol is modeled at a highly ab-stract level and the underlying cryptographic primitives are treated as secure“black boxes”to simplify the model.This approach discovers attacks that would succeed even if all cryptographic functions were perfectly secure.Conventional formal analysis of security is mainly concerned with security against the so called Dolev-Yao attacks,following[DY83].A Dolev-Yao attacker is a non-deterministic process that has complete control over the communication net-work and can perform any combination of a given set of attacker operations,such as intercepting any message,splitting messages into parts,decrypting if it knows the correct decryption key,assembling fragments of messages into new messages and replaying them out of context,etc.Many proposed systems for anonymous communication aim to provide strong, non-probabilistic anonymity guarantees.This includes proxy-based approaches to anonymity such as the Anonymizer[Ano],which hide the sender’s identity for each message by forwarding all communication through a special server,and MIX-based anonymity systems[Cha81]that blend communication between dif-ferent senders and recipients,thus preventing a global eavesdropper from linking sender-recipient pairs.Non-probabilistic anonymity systems are amenable to for-mal analysis in the same non-deterministic Dolev-Yao model as used for verifica-tion of secrecy and authentication protocols.Existing techniques for the formal analysis of anonymity in the non-deterministic model include traditional process formalisms such as CSP[SS96]and a special-purpose logic of knowledge[SS99].In this paper,we use probabilistic model checking to analyze anonymity prop-erties of a gossip-based system.Such systems fundamentally rely on probabilistic message routing to guarantee anonymity.The main representative of this class of anonymity systems is Crowds[RR98].Instead of protecting the user’s identity against a global eavesdropper,Crowds provides protection against collaborating local eavesdroppers.All communication is routed randomly through a group of peers,so that even if some of the group members collaborate and share collected lo-cal information with the adversary,the latter is not likely to distinguish true senders of the observed messages from randomly selected forwarders.Conventional formal analysis techniques that assume a non-deterministic at-tacker in full control of the communication channels are not applicable in this case. Security properties of gossip-based systems depend solely on the probabilistic be-havior of protocol participants,and can be formally expressed only in terms of relative probabilities of certain observations by the adversary.The system must be modeled as a probabilistic process in order to capture its properties faithfully.Using the analysis technique developed in this paper—namely,formalization of the system as a discrete-time Markov chain and probabilistic model checking of2this chain with PRISM—we uncovered two subtle properties of Crowds that causedegradation of the level of anonymity provided by the system to the users.First,if corrupt group members are able to detect that messages along different routingpaths originate from the same(unknown)sender,the probability of identifyingthat sender increases as the number of observed paths grows(the number of pathsmust grow with time since paths are rebuilt when crowd membership changes).Second,the confidence of the corrupt members that they detected the correct senderincreases with the size of the group.Thefirstflaw was reported independently byMalkhi[Mal01]and Wright et al.[W ALS02],while the second,to the best ofour knowledge,was reported for thefirst time in the conference version of thispaper[Shm02].In contrast to the analysis by Wright et al.that relies on manualprobability calculations,we discovered both potential vulnerabilities of Crowds byautomated probabilistic model checking.Previous research on probabilistic formal models for security focused on(i)probabilistic characterization of non-interference[Gra92,SG95,VS98],and(ii)process formalisms that aim to faithfully model probabilistic properties of crypto-graphic primitives[LMMS99,Can00].This paper attempts to directly model andanalyze security properties based on discrete probabilities,as opposed to asymp-totic probabilities in the conventional cryptographic sense.Our analysis methodis applicable to other probabilistic anonymity systems such as Freenet[CSWH01]and onion routing[SGR97].Note that the potential vulnerabilities we discovered inthe formal model of Crowds may not manifest themselves in the implementationsof Crowds or other,similar systems that take measures to prevent corrupt routersfrom correlating multiple paths originating from the same sender.2Markov Chain Model CheckingWe model the probabilistic behavior of a peer-to-peer communication system as adiscrete-time Markov chain(DTMC),which is a standard approach in probabilisticverification[LS82,HS84,Var85,HJ94].Formally,a Markov chain can be definedas consisting in afinite set of states,the initial state,the transition relation such that,and a labeling functionfrom states to afinite set of propositions.In our model,the states of the Markov chain will represent different stages ofrouting path construction.As usual,a state is defined by the values of all systemvariables.For each state,the corresponding row of the transition matrix de-fines the probability distributions which govern the behavior of group members once the system reaches that state.32.1Overview of PCTLWe use the temporal probabilistic logic PCTL[HJ94]to formally specify properties of the system to be checked.PCTL can express properties of the form“under any scheduling of processes,the probability that event occurs is at least.”First,define state formulas inductively as follows:where atomic propositions are predicates over state variables.State formulas of the form are explained below.Define path formulas as follows:Unlike state formulas,which are simplyfirst-order propositions over a single state,path formulas represent properties of a chain of states(here path refers to a sequence of state space transitions rather than a routing path in the Crowds speci-fication).In particular,is true iff is true for every state in the chain;is true iff is true for all states in the chain until becomes true,and is true for all subsequent states;is true iff and there are no more than states before becomes true.For any state and path formula,is a state formula which is true iff state space paths starting from satisfy path formula with probability greater than.For the purposes of this paper,we will be interested in formulas of the form ,evaluated in the initial state.Here specifies a system con-figuration of interest,typically representing a particular observation by the adver-sary that satisfies the definition of a successful attack on the protocol.Property is a liveness property:it holds in iff will eventually hold with greater than probability.For instance,if is a state variable represent-ing the number of times one of the corrupt members received a message from the honest member no.,then holds in iff the prob-ability of corrupt members eventually observing member no.twice or more is greater than.Expressing properties of the system in PCTL allows us to reason formally about the probability of corrupt group members collecting enough evidence to success-fully attack anonymity.We use model checking techniques developed for verifica-tion of discrete-time Markov chains to compute this probability automatically.42.2PRISM model checkerThe automated analyses described in this paper were performed using PRISM,aprobabilistic model checker developed by Kwiatkowska et al.[KNP01].The toolsupports both discrete-and continuous-time Markov chains,and Markov decisionprocesses.As described in section4,we model probabilistic peer-to-peer com-munication systems such as Crowds simply as discrete-time Markov chains,andformalize their properties in PCTL.The behavior of the system processes is specified using a simple module-basedlanguage inspired by Reactive Modules[AH96].State variables are declared in thestandard way.For example,the following declarationdeliver:bool init false;declares a boolean state variable deliver,initialized to false,while the followingdeclarationconst TotalRuns=4;...observe1:[0..TotalRuns]init0;declares a constant TotalRuns equal to,and then an integer array of size,indexed from to TotalRuns,with all elements initialized to.State transition rules are specified using guarded commands of the form[]<guard>-><command>;where<guard>is a predicate over system variables,and<command>is the tran-sition executed by the system if the guard condition evaluates to mandoften has the form<expression>...<expression>, which means that in the next state(i.e.,that obtained after the transition has beenexecuted),state variable is assigned the result of evaluating arithmetic expres-sion<expression>If the transition must be chosen probabilistically,the discrete probability dis-tribution is specified as[]<guard>-><prob1>:<command1>+...+<probN>:<commandN>;Transition represented by command is executed with probability prob,and prob.Security properties to be checked are stated as PCTL formulas (see section2.1).5Given a formal system specification,PRISM constructs the Markov chain and determines the set of reachable states,using MTBDDs and BDDs,respectively. Model checking a PCTL formula reduces to a combination of reachability-based computation and solving a system of linear equations to determine the probability of satisfying the formula in each reachable state.The model checking algorithms employed by PRISM include[BdA95,BK98,Bai98].More details about the im-plementation and operation of PRISM can be found at http://www.cs.bham. /˜dxp/prism/and in[KNP01].Since PRISM only supports model checking offinite DTMC,in our case study of Crowds we only analyze anonymity properties offinite instances of the system. By changing parameters of the model,we demonstrate how anonymity properties evolve with changes in the system configuration.Wright et al.[W ALS02]investi-gated related properties of the Crowds system in the general case,but they do not rely on tool support and their analyses are manual rather than automated.3Crowds Anonymity SystemProviding an anonymous communication service on the Internet is a challenging task.While conventional security mechanisms such as encryption can be used to protect the content of messages and transactions,eavesdroppers can still observe the IP addresses of communicating computers,timing and frequency of communi-cation,etc.A Web server can trace the source of the incoming connection,further compromising anonymity.The Crowds system was developed by Reiter and Ru-bin[RR98]for protecting users’anonymity on the Web.The main idea behind gossip-based approaches to anonymity such as Crowds is to hide each user’s communications by routing them randomly within a crowd of similar users.Even if an eavesdropper observes a message being sent by a particular user,it can never be sure whether the user is the actual sender,or is simply routing another user’s message.3.1Path setup protocolA crowd is a collection of users,each of whom is running a special process called a jondo which acts as the user’s proxy.Some of the jondos may be corrupt and/or controlled by the adversary.Corrupt jondos may collaborate and share their obser-vations in an attempt to compromise the honest users’anonymity.Note,however, that all observations by corrupt group members are local.Each corrupt member may observe messages sent to it,but not messages transmitted on the links be-tween honest jondos.An honest crowd member has no way of determining whether6a particular jondo is honest or corrupt.The parameters of the system are the total number of members,the number of corrupt members,and the forwarding probability which is explained below.To participate in communication,all jondos must register with a special server which maintains membership information.Therefore,every member of the crowd knows identities of all other members.As part of the join procedure,the members establish pairwise encryption keys which are used to encrypt pairwise communi-cation,so the contents of the messages are secret from an external eavesdropper.Anonymity guarantees provided by Crowds are based on the path setup pro-tocol,which is described in the rest of this section.The path setup protocol is executed each time one of the crowd members wants to establish an anonymous connection to a Web server.Once a routing path through the crowd is established, all subsequent communication between the member and the Web server is routed along it.We will call one run of the path setup protocol a session.When crowd membership changes,the existing paths must be scrapped and a new protocol ses-sion must be executed in order to create a new random routing path through the crowd to the destination.Therefore,we’ll use terms path reformulation and proto-col session interchangeably.When a user wants to establish a connection with a Web server,its browser sends a request to the jondo running locally on her computer(we will call this jondo the initiator).Each request contains information about the intended desti-nation.Since the objective of Crowds is to protect the sender’s identity,it is not problematic that a corrupt router can learn the recipient’s identity.The initiator starts the process of creating a random path to the destination as follows: The initiator selects a crowd member at random(possibly itself),and for-wards the request to it,encrypted by the corresponding pairwise key.We’ll call the selected member the forwarder.The forwarderflips a biased coin.With probability,it delivers the request directly to the destination.With probability,it selects a crowd member at random(possibly itself)as the next forwarder in the path,and forwards the request to it,re-encrypted with the appropriate pairwise key.The next forwarder then repeats this step.Each forwarder maintains an identifier for the created path.If the same jondo appears in different positions on the same path,identifiers are different to avoid infinite loops.Each subsequent message from the initiator to the destination is routed along this path,i.e.,the paths are static—once established,they are not altered often.This is necessary to hinder corrupt members from linking multiple7paths originating from the same initiator,and using this information to compromise the initiator’s anonymity as described in section3.2.3.3.2Anonymity properties of CrowdsThe Crowds paper[RR98]describes several degrees of anonymity that may be provided by a communication system.Without using anonymizing techniques, none of the following properties are guaranteed on the Web since browser requests contain information about their source and destination in the clear.Beyond suspicion Even if the adversary can see evidence of a sent message,the real sender appears to be no more likely to have originated it than any other potential sender in the system.Probable innocence The real sender appears no more likely to be the originator of the message than to not be the originator,i.e.,the probability that the adversary observes the real sender as the source of the message is less thanupper bound on the probability of detection.If the sender is observed by the adversary,she can then plausibly argue that she has been routing someone else’s messages.The Crowds paper focuses on providing anonymity against local,possibly co-operating eavesdroppers,who can share their observations of communication in which they are involved as forwarders,but cannot observe communication involv-ing only honest members.We also limit our analysis to this case.3.2.1Anonymity for a single routeIt is proved in[RR98]that,for any given routing path,the path initiator in a crowd of members with forwarding probability has probable innocence against collaborating crowd members if the following inequality holds:(1)More formally,let be the event that at least one of the corrupt crowd members is selected for the path,and be the event that the path initiator appears in8the path immediately before a corrupt crowd member(i.e.,the adversary observes the real sender as the source of the messages routed along the path).Condition 1guarantees thatproving that,given multiple linked paths,the initiator appears more often as a sus-pect than a random crowd member.The automated analysis described in section6.1 confirms and quantifies this result.(The technical results of[Shm02]on which this paper is based had been developed independently of[Mal01]and[W ALS02],be-fore the latter was published).In general,[Mal01]and[W ALS02]conjecture that there can be no reliable anonymity method for peer-to-peer communication if in order to start a new communication session,the initiator must originate thefirst connection before any processing of the session commences.This implies that anonymity is impossible in a gossip-based system with corrupt routers in the ab-sence of decoy traffic.In section6.3,we show that,for any given number of observed paths,the adversary’s confidence in its observations increases with the size of the crowd.This result contradicts the intuitive notion that bigger crowds provide better anonymity guarantees.It was discovered by automated analysis.4Formal Model of CrowdsIn this section,we describe our probabilistic formal model of the Crowds system. Since there is no non-determinism in the protocol specification(see section3.1), the model is a simple discrete-time Markov chain as opposed to a Markov deci-sion process.In addition to modeling the behavior of the honest crowd members, we also formalize the adversary.The protocol does not aim to provide anonymity against global eavesdroppers.Therefore,it is sufficient to model the adversary as a coalition of corrupt crowd members who only have access to local communication channels,i.e.,they can only make observations about a path if one of them is se-lected as a forwarder.By the same token,it is not necessary to model cryptographic functions,since corrupt members know the keys used to encrypt peer-to-peer links in which they are one of the endpoints,and have no access to links that involve only honest members.The modeling technique presented in this section is applicable with minor mod-ifications to any probabilistic routing system.In each state of routing path construc-tion,the discrete probability distribution given by the protocol specification is used directly to define the probabilistic transition rule for choosing the next forwarder on the path,if any.If the protocol prescribes an upper bound on the length of the path(e.g.,Freenet[CSWH01]),the bound can be introduced as a system parameter as described in section4.2.3,with the corresponding increase in the size of the state space but no conceptual problems.Probabilistic model checking can then be used to check the validity of PCTL formulas representing properties of the system.In the general case,forwarder selection may be governed by non-deterministic10runCount goodbad lastSeen observelaunchnewstartrundeliver recordLast badObserve4.2Model of honest members4.2.1InitiationPath construction is initiated as follows(syntax of PRISM is described in section 2.2):[]launch->runCount’=TotalRuns&new’=true&launch’=false;[]new&(runCount>0)->(runCount’=runCount-1)&new’=false&start’=true;[]start->lastSeen’=0&deliver’=false&run’=true&start’=false;4.2.2Forwarder selectionThe initiator(i.e.,thefirst crowd member on the path,the one whose identity must be protected)randomly chooses thefirst forwarder from among all group mem-bers.We assume that all group members have an equal probability of being chosen, but the technique can support any discrete probability distribution for choosing for-warders.Forwarder selection is a single step of the protocol,but we model it as two probabilistic state transitions.Thefirst determines whether the selected forwarder is honest or corrupt,the second determines the forwarder’s identity.The randomly selected forwarder is corrupt with probability badCbe next on the path.Any of the honest crowd members can be selected as the forwarder with equal probability.To illustrate,for a crowd with10honest members,the following transition models the second step of forwarder selection: []recordLast&CrowdSize=10->0.1:lastSeen’=0&run’=true&recordLast’=false+0.1:lastSeen’=1&run’=true&recordLast’=false+...0.1:lastSeen’=9&run’=true&recordLast’=false;According to the protocol,each honest crowd member must decide whether to continue building the path byflipping a biased coin.With probability,the forwarder selection transition is enabled again and path construction continues, and with probability the path is terminated at the current forwarder,and all requests arriving from the initiator along the path will be delivered directly to the recipient.[](good&!deliver&run)->//Continue path constructionPF:good’=false+//Terminate path constructionnotPF:deliver’=true;The specification of the Crowds system imposes no upper bound on the length of the path.Moreover,the forwarders are not permitted to know their relative position on the path.Note,however,that the amount of information about the initiator that can be extracted by the adversary from any path,or anyfinite number of paths,isfinite(see sections4.3and4.5).In systems such as Freenet[CSWH01],requests have a hops-to-live counter to prevent infinite paths,except with very small probability.To model this counter,we may introduce an additional state variable pIndex that keeps track of the length of the path constructed so far.The path construction transition is then coded as follows://Example with Hops-To-Live//(NOT CROWDS)////Forward with prob.PF,else deliver13[](good&!deliver&run&pIndex<MaxPath)->PF:good’=false&pIndex’=pIndex+1+notPF:deliver’=true;//Terminate if reached MaxPath,//but sometimes not//(to confuse adversary)[](good&!deliver&run&pIndex=MaxPath)->smallP:good’=false+largeP:deliver’=true;Introduction of pIndex obviously results in exponential state space explosion, decreasing the maximum system size for which model checking is feasible.4.2.4Transition matrix for honest membersTo summarize the state space of the discrete-time Markov chain representing cor-rect behavior of protocol participants(i.e.,the state space induced by the abovetransitions),let be the state in which links of the th routing path from the initiator have already been constructed,and assume that are the honestforwarders selected for the path.Let be the state in which path constructionhas terminated with as thefinal path,and let be an auxiliary state. Then,given the set of honest crowd members s.t.,the transi-tion matrix is such that,,(see section4.2.2),i.e.,the probability of selecting the adversary is equal to the cumulative probability of selecting some corrupt member.14This abstraction does not limit the class of attacks that can be discovered using the approach proposed in this paper.Any attack found in the model where indi-vidual corrupt members are kept separate will be found in the model where their capabilities are combined in a single worst-case adversary.The reason for this is that every observation made by one of the corrupt members in the model with separate corrupt members will be made by the adversary in the model where their capabilities are combined.The amount of information available to the worst-case adversary and,consequently,the inferences that can be made from it are at least as large as those available to any individual corrupt member or a subset thereof.In the adversary model of[RR98],each corrupt member can only observe its local network.Therefore,it only learns the identity of the crowd member imme-diately preceding it on the path.We model this by having the corrupt member read the value of the lastSeen variable,and record its observations.This cor-responds to reading the source IP address of the messages arriving along the path. For example,for a crowd of size10,the transition is as follows:[]lastSeen=0&badObserve->observe0’=observe0+1&deliver’=true&run’=true&badObserve’=false;...[]lastSeen=9&badObserve->observe9’=observe9+1&deliver’=true&run’=true&badObserve’=false;The counters observe are persistent,i.e.,they are not reset for each session of the path setup protocol.This allows the adversary to accumulate observations over several path reformulations.We assume that the adversary can detect when two paths originate from the same member whose identity is unknown(see sec-tion3.2.2).The adversary is only interested in learning the identity of thefirst crowd mem-ber in the path.Continuing path construction after one of the corrupt members has been selected as a forwarder does not provide the adversary with any new infor-mation.This is a very important property since it helps keep the model of the adversaryfinite.Even though there is no bound on the length of the path,at most one observation per path is useful to the adversary.To simplify the model,we as-sume that the path terminates as soon as it reaches a corrupt member(modeled by deliver’=true in the transition above).This is done to shorten the average path length without decreasing the power of the adversary.15Each forwarder is supposed toflip a biased coin to decide whether to terminate the path,but the coinflips are local to the forwarder and cannot be observed by other members.Therefore,honest members cannot detect without cooperation that corrupt members always terminate paths.In any case,corrupt members can make their observable behavior indistinguishable from that of the honest members by continuing the path with probability as described in section4.2.3,even though this yields no additional information to the adversary.4.4Multiple pathsThe discrete-time Markov chain defined in sections4.2and4.3models construc-tion of a single path through the crowd.As explained in section3.2.2,paths have to be reformulated periodically.The decision to rebuild the path is typically made according to a pre-determined schedule,e.g.,hourly,daily,or once enough new members have asked to join the crowd.For the purposes of our analysis,we sim-ply assume that paths are reformulated somefinite number of times(determined by the system parameter=TotalRuns).We analyze anonymity properties provided by Crowds after successive path reformulations by considering the state space produced by successive execu-tions of the path construction protocol described in section4.2.As explained in section4.3,the adversary is permitted to combine its observations of some or all of the paths that have been constructed(the adversary only observes the paths for which some corrupt member was selected as one of the forwarders).The adversary may then use this information to infer the path initiator’s identity.Because for-warder selection is probabilistic,the adversary’s ability to collect enough informa-tion to successfully identify the initiator can only be characterized probabilistically, as explained in section5.4.5Finiteness of the adversary’s state spaceThe state space of the honest members defined by the transition matrix of sec-tion4.2.4is infinite since there is no a priori upper bound on the length of each path.Corrupt members,however,even if they collaborate,can make at most one observation per path,as explained in section4.3.As long as the number of path reformulations is bounded(see section4.4),only afinite number of paths will be constructed and the adversary will be able to make only afinite number of observa-tions.Therefore,the adversary only needsfinite memory and the adversary’s state space isfinite.In general,anonymity is violated if the adversary has a high probability of making a certain observation(see section5).Tofind out whether Crowds satisfies16。
vda-quality-related-cost质量成本-英文版

with the support of the Department of Quality Science at the Technische Universität Berlin. We would also like to thank all concerned for their suggestions regarding the elaboration and improvement of this publication.
1 Edition, April 2015 Verband der Automobilindustrie e. V. (VDA)
st
NOT FOR SALE | free version here: www.vda-qmc.de/publikationen/download/ | April 2015
Berlin, November 2014 Verband der Automobilindustrie e. V. (VDA)
NOT FOR SALE | free version here: www.vda-qmc.de/publikationen/download/ | April 2015
4
6
1
Object and purpose
Before this VDA volume was published, no standardized definitions of terms regarding quality-related costs in the automotive industry existed. However, in order to be able to manage quality processes – even in the supply chain – defined standardized understanding is essential. By defining the term ‘quality-related costs’ and establishing a method to report quality failure costs in a practicable way, this VDA red volume closes this gap. The concept of quality failure cost reporting enables companies to extend their quality reporting in a targeted manner, as well as to optimize the management of their improvement measures; the obligation to disclose failure costs in cooperations between companies is excluded. Current business cost calculations do not generally allow failure prevention costs to be isolated or ascertained.
一种动态消减时间自动机可达性搜索空间的方法

3)本课题研究得到国家自然科学基金(No.60573085)和国家重点基础研究973计划(No.2002CB312001)的资助。
陈铭松 硕士研究生,主要研究方向为模型检验、软件测试;赵建华 教授,硕导,主要研究方向为形式化方法、软件工程及程序设计语言;李宣东 教授,博导,主要研究方向为面向对象技术、形式化方法;郑国梁 教授,博导,主要研究方向为软件工程、软件开发环境及面向对象技术。
计算机科学2007Vol 134№11一种动态消减时间自动机可达性搜索空间的方法3)陈铭松 赵建华 李宣东 郑国梁(南京大学计算机软件新技术国家重点实验室,南京大学计算机科学与技术系 南京210093)摘 要 时间自动机的可达性分析算法通常采用对符号状态的枚举来遍历其状态空间。
符号状态由位置与时间区域组成,时间区域用形如x -y ≤(<)n 的原子公式的合取式来表示。
在对时间自动机进行可达性分析的过程中,分析算法将生成大量的符号状态,往往导致对计算机内存的需求超出了可行的范围。
本文给出了一个消减符号状态个数的方法。
该方法通过对符号状态间的依赖关系进行分析,在不影响分析结果的前提下消去某些时间区域的原子公式,从而扩展符号状态。
扩展后的符号状态包含有更加多的其它的状态,通过删除掉那些被包含的符号状态可以减少算法存储的状态个数,节省存储空间。
本文最后给出了相关的案例分析,结果表明这个算法有效地减少了某些时间自动机可达性分析过程中所需的存储空间。
关键词 时间自动机,模型检验,符号状态,时间区域 An Algorithm to Dynamically R educe the State Space of TimedAutomata during the R eachability AnalysisCH EN Ming 2Song ZHAO Jian 2Hua L I Xuan 2Dong ZH EN G Guo 2Liang(National Laboratory of Novel Software Technology ,Depart ment of Computer Science and Technology ,Nanjing University ,Nanjing 210093)Abstract The reachability analysis algorithm explores the state space of a timed automaton by enumeration of symbolic states.Each symbolic state consists of a location and a time zone which are conjunctions of automatic formulae in the form x -y ≤(<)n .Sometimes the amount of generated symbolic states is very large ,the memory required to store the generated symbolic states is not feasible.In this paper ,we present an approach to reduce the memory requirement of the reachability analysis algorithm.By analyzing the dependence relation between symbolic states ,we can expand some of the symbolic states by removing specific kinds of atomic formulae without changing the reachability analysis re 2sult.The expanded states can contain more symbolic states.Removing these contained states can reduce the memory requirement of reachability analysis.The case studies presented in this paper show that our algorithm can save memory in the practical application efficiently.K eyw ords Timed automata ,Model checking ,Symbolic state ,Time zone 1 引言模型检验(model checking )[1]是一种被用来自动验证有穷状态系统的形式化技术。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Automatic verification of deontic properties ofmulti-agent systemsFranco Raimondi and Alessio LomuscioDepartment of Computer ScienceKing’s College LondonLondon,UKfranco,alessio@Abstract.We present an algorithm and its implementation for the verification ofcorrect behaviour and epistemic states in multiagent systems.The verification isperformed via model checking techniques based on OBDD’s.We test our imple-mentation by means of a communication example:the bit transmission problemwith faults.1IntroductionIn the last two decades,the paradigm of multiagent systems(MAS)has been employed successfully in severalfields,including,for example,philosophy,economics,and soft-ware engineering.One of the reasons for the use of MAS formalism in such different fields is the usefulness of ascribing autonomous and social behaviour to the components of a system of agents.This allows to abstract from the details of the components,and to focus on the interaction among the various agents.Besides abstracting and specifying the behaviour of a complex system by means of MAS formalisms based on logic,recently researchers have been concerned with the problem of verifying MAS,i.e.,with the problem of certifying formally that a MAS satisfies its specification.Formal verification has its roots in software engineering,where it is used to verify whether or not a system behaves as it is supposed to.One of the most successful for-mal approaches to verification is model checking.In this approach,the system to be verified is represented by means of a logical model representing the computational traces of the system,and the property to be checked is expressed via a logical formula .Verification via model checking is defined as the problem of establishing whether or not.Various tools have been built to perform this task automatically,and many real-life scenarios have been tested.Unfortunately,extending model checking techniques for the verification of MAS does not seem to be an easy task.This is because model checking tools consider stan-dard reactive systems,and do not allow for the representation of the social interaction and the autonomous behaviour of agents.Specifically,traditional model checking tools assume that is“simply”a temporal model,while MAS need more complex for-malisms.Typically,in MAS we want to reason about epistemic,deontic,and doxastic properties of agents,and their temporal evolution.Hence,the logical models required are richer than the temporal model used in traditional model checking.Various ideas have been put forward to verify MAS.In[20],M.Wooldridge et al. present the MABLE language for the specification of MAS.In this work,non-temporal modalities are translated into nested data structures(in the spirit of[1]).Bordini et al.[2] use a modified version of the AgentSpeak(L)language[18]to specify agents and to ex-ploit existing model checkers.Both the works of M.Wooldridge et al.and of Bordini et al.translate the MAS specification into a SPIN specification to perform the verification. In this line,the attitudes for the agents are reduced to predicates,and the verification involves only the temporal verification of those.In[8]a methodology is provided to translate a deontic interpreted system into SMV code,but the verification is limited to static deontic and epistemic properties,i.e.the temporal dimension is not present, and the approach is not fully symbolic.The works of van der Meyden and Shilov[12], and van der Meyden and Su[13],are concerned with the verification of temporal and epistemic properties of MAS.They consider a particular class of interpreted systems: synchronous distributed systems with perfect recall.An automata-based algorithm for model checking is introduced in thefirst paper using automata.In[13]an example is presented,and[13]suggests the use of OBDD’s for this approach,but no algorithm or implementation is provided.In this paper we introduce an algorithm to model check MAS via OBDD’s.In par-ticular,in this work we investigate the verification of epistemic properties of MAS,and the verification of the“correct”behaviour of agents.Knowledge is a fundamental property of the agents,and it has been used for decades as key concept to reason about systems[5].In complex systems,reasoning about the “correct”behaviour is also crucial.As an example,consider a client-server interaction in which a server fails to respond as quickly as it is supposed to a client’s requests.This is an unwanted behaviour that may,in certain circumstances,crash the client.It has been shown[14]that correct behaviour can be represented by means of deontic concepts:as we show in this paper,model checking deontic properties can help in establishing the extent in which a system can cope with failures.We give an example of this in Sec-tion5.2,where two possible“faulty”behaviours are considered in the bit transmission problem[5],and key properties of the agents are analysed under these assumptions.In one case,the incorrect behaviour does not cause the whole system to fail;in the second case,the incorrect behaviour invalidates required properties of the system.We use this as a test example,but we feel that similar situations can arise in many areas,including database management,distributed applications,communication scenarios,etc.The rest of the paper is organised as follows.In Section2we review the formal-ism of deontic interpreted systems and model checking via OBDD’s.In Section3we introduce an algorithm for the verification of deontic interpreted systems.An imple-mentation of the algorithm is then discussed in Section4.In Section5we test our implementation by means of an example:the bit transmission problem with faults.We conclude in Section6.2PreliminariesIn this section we introduce the formalisms and the notation used in the rest of the paper. In Section2.1we review briefly the formalism of interpreted systems as presented in[5]to model a MAS,and its extension to reason about the correct behaviour of some of theagents as presented in[9].In Section2.2we review some model checking methodolo-gies.2.1Deontic interpreted systems and their temporal extensionAn interpreted system[5]is a semantic structure representing a system of agents.Each agent in the system()is characterised by a set of local states and bya set of actions that may be performed.Actions are performed in compliance witha protocol(notice that this definition allows for non-determinism).A tuple,where for each,is called a global stateand gives a description of the system at a particular instance of time.Given a set ofinitial global states,the evolution of the system is described by evolution functions (this definition is equivalent to the definition of a single evolution function as in[5]):.In this formalism,the environment in which agents“live”is usually modelled by means of a special agent;we referto[5]for more details.The set,the functions,and the protocols generate a setof computations(also called runs).Formally,a computation is a sequence of global states such that and,for each pair,there exists a set of actions enabled by the protocols such that.denotes the set of reachable global states.In[9]the notion of correct behaviour of the agents is incorporated in this formal-ism.This is done by dividing the set of local states into two disjoint sets:a non-empty set of allowed(or“green”)states,and a set of disallowed(or faulty,or“red”) states,such that,and.Given a countable set of propositional variables and a valuation function for the atoms,a deon-tic interpreted systems is a tuple.The relations are epistemic accessibility relations defined for each agent by:iff,i.e.if the local state of agent is the same in and in(notice that this is an equivalence relation).The relations are accessibility relations defined by iff,i.e.if the local state of in is a“green”state.We refer to[9] for more details.Deontic interpreted systems can be used to evaluate formulae involv-ing various modal operators.Besides the standard boolean connectives,the language considered in[9]includes:–A deontic operator,denoting the fact that under all the correct alternatives for agent,holds.–An epistemic operator,whose meaning is agent knows.–A particular form of knowledge denoting the knowledge about a fact that an agent has on the assumption that agent is functioning correctly.We extend this language by introducing the following temporal operators:.Formally,the language we use is defined as follows:We now define the semantics for this language.Given a deontic interpreted system ,a global state,and a formula,satisfaction is defined as follows:iff,iff,iff or,iff there exists a computation such that and,iff there exists a computation such that andfor all.iff there exists a computation such that and a suchthat and for all,iff,impliesiff,impliesiff,and impliesIn the definition above,denotes the global state at place in computation.Other temporal modalities can be derived,namely.We refer to[5,9, 15]for more details.2.2Model checking techniquesThe problem of model checking can be defined as establishing whether or not a model satisfies a formula().Though could be a model for any logic,tradition-ally the problem of building tools to perform model checking automatically has been investigated almost only for temporal logics[4,7].The model is usually represented by means of a dedicated programming lan-guage,such as PROMELA[6]or SMV[11].The verification step avoids building the model explicitly from the program;instead,various techniques have been inves-tigated to perform a symbolic representation of the model and the parameters neededby verification algorithms.Such techniques are based on automata[6],ordered binary decision diagrams(OBDD’s,[3]),or other algebraic structures.These approaches are often referred to as symbolic model checking techniques.For the purpose of this paper,we review briefly symbolic model checking using OBDD’s.It has been shown that OBDD’s offer a compact representation of boolean functions.As an example,consider the boolean function.The truth table of this function would be8lines long.Equivalently,one can evaluate the truth value of this function by representing the function as a directed graph,as exemplified on the left-hand side of Figure1.As it is clear from the picture,under certain assumptions,this graph can be simplified into the graph pictured on the right-hand side of Figure1.This“reduced”representation is called the OBDD of the boolean function.Besides offering a compact representation of boolean functions,OBDD’s of different functions can be composedefficiently.We refer to[3,11]for more details.The key idea of model checking temporal logics using OBDD’s is to represent the model and all the parameters needed by the algorithms by means of boolean func-tions.These boolean functions can then be encoded as OBDD’s,and the verification step can operate directly on these.The verification is performed usingfix-point character-isation of the temporal logics operators.We refer to[7]for more ing this technique,systems with a state space in the region of have been verified.abb cc 0101011000011a b c 10100101Fig.1.OBDD representation for .3Model checking deontic properties of interpreted systemsIn this section we present an algorithm for the verification of deontic,epistemic,and temporal modalities of MAS,extending with deontic modalities the work that appeared in [17].Our approach is similar,in spirit,to the traditional model checking techniques for the logic CTL.Indeed,we start in Section 3.1by representing the various parameters of the system by means of boolean formulae.In Section 3.2,we provide and algorithm based on this representation for the verification step.The whole technique uses deontic interpreted systems as its underlying semantics.3.1From deontic interpreted systems to boolean formulaeIn this section we translate a deontic interpreted system into boolean formulae.As boolean formulae are built using boolean variables,we begin by computing the re-quired number of boolean variables.To encode local states of an agent,the number of boolean variables required is .To encode actions,the number of variables required is.Hence,given ,a global state can be encoded by means boolean variables:.Similarly,given,a joint action can be encoded as .Having encoded local states,global states,and actions by means of boolean vari-ables,all the remaining parameters can be expressed as boolean functions as follows.The protocols relate local states to set of actions,and can be expressed as boolean for-mulae.The evolution functions can be translated into boolean formulae,too.Indeed,the definition of in Section 2.1can be seen as specifying a list of conditionsunder which agent changes the value of its local state.Each has the form “if [con-ditions on global state and actions]then [value of “next”local state for ]”.Hence,is expressed as a boolean formula as follows:where denotesexclusive-or.We assume that the last conditionof prescribes that,if none of the conditions on global states and actions in is true,then the local state for does not change.This assumption is key to keep compact the description of the sys-tem,so that only the conditions causing a change in the configuration of the system need to be listed.The evaluation function associates a set of global states to each propositional atom,and so it can be translated into a boolean function.In addition to these parameters,the algorithm presented in Section3.2requires the definition of a boolean function representing a temporal relation between and.can be obtained from the evolution functions as follows.First,we introduce a global evolution function:Notice that is a boolean function involving two global states and a joint action .To abstract from the joint action and obtain a boolean function relating two global states only,we can define as follows:iff is true and each local action is enabled by the protocol of agent in the local state.The quantification over actions above can be translated into a propositional formula using a disjunction(see[11,4]for a similar approach to boolean quantification):where is a boolean formula imposing that the joint action must be consistent with the agents’protocols in global state.The relation gives the desired boolean relation between global states.3.2The algorithmIn this section we present the algorithm to compute the set of global states in which a formula holds.The following are the parameters needed by the algorithm:–the boolean variables and encoding global states and joint actions;–boolean functions encoding the protocols of the agents;–the function returning the set of global states in which the atomic proposition holds.We assume that the global states are returned encoded as a boolean function of;–the set of initial states,encoded as a boolean function;–the set of reachable states.This can be computed as thefix-point of the operatorwhere is true if is an initial state and denotes a set of global states.Thefix-point of can be computed by iteratingby standard procedure(see[11]);–the boolean function encoding the temporal transition;–boolean functions encoding the accessibility relations(these functions are defined using equivalence on local states of);–boolean functions encoding the deontic accessibility relations.The algorithm is as follows:is an atomic formula:return;is:return;is:return;is:return;is:return;is:return;is:return;is:return;is:return;In the algorithm above,,,are the standard procedures for CTL model checking[7],in which the temporal relation is and,instead of tempo-ral states,global states are considered.The procedures,and return a set of states in which the formulae,and are true.Their implementation is presented below.X=;Y=andreturn Y;X=;Y=andreturn Y;X=;Y=and andreturn Y;Notice that all the parameters can be encoded as OBDD’s.Moreover,all the operations in the algorithms can be performed on OBDD’s.The algorithm presented here computes the set of states in which a formula holds, but we are usually interested in checking whether or not a formula holds in the whole model.can be used to verify whether or not a formula holds in a model by comparing two set of states:the set and the set of reachable states.As sets of states are expressed as OBDD’s,verification in a model is reduced to the comparison of the two OBDD’s for and for.4ImplementationIn this section we present an implementation of the algorithm introduced in Section3. In Section4.1we define a language to encode deontic interpreted systems symbolically, while in Section4.2we describe how the language is translated into OBDD’s and how the algorithm is implemented.The implementation is available for download[16].4.1How to define a deontic interpreted systemTo define a deontic interpreted system it is necessary to specify all the parameters pre-sented in Section2.1.In other words,for each agent,we need to represent:–a list of local states,and a list of“green”local states;–a list of actions;–a protocol for the agent;–an evolution function for the agent.In our implementation,the parameters listed above are provided via a textfile.The formal syntax of a textfile specifying a list of agents is as follows:agentlist::=agentdef|agentlist agentdefagentdef::="Agent"IDLstateDef;LgreenDef;ActionDef;ProtocolDef;EvolutionDef;"end Agent"LstateDef::="Lstate={"IDLIST"}"LgreenDef::="Lgreen={"IDLIST"}"ActionDef::="Action={"IDLIST"}"ProtocolDef::="Protocol"ID":{"IDLIST"}";..."end Protocol"EvolutionDef::="Ev:"ID"if"BOOLEANCOND;..."end Ev"IDLIST::=ID|IDLIST","IDID::=[a-zA-Z][a-zA-Z0-9_]*In the definition above,BOOLEANCOND is a string expressing a boolean condition;we omit its description here and we refer to the source code for more details.To com-plete the specification of a deontic interpreted system,it is also necessary to define the following parameters:–an evaluation function;–a set of initial states(expressed as a boolean condition);–a list of subsets of the set of agents to be used for particular group modalitiesThe syntax for this set of parameters is as follows:EvaluationDef::="Evaluation"ID"if"BOOLEANCOND;..."end Evaluation"InitstatesDef::="InitStates"BOOLEANCOND;"end InitStates"GroupDef::="Groups"ID"={"IDLIST"}";..."end Groups"Due to space limitations we refer to thefiles available online for a full example of specification of an interpreted system.Formulae to be checked are specified using the following syntaxformula::=ID|formula"AND"formula|"NOT"formula|"EX("formula")"|"EG("formula")"|"E("formula"U"formula")"|"K("ID","formula")"|"O("ID","formula")"|"KH("ID","ID","formula")"Above,K denotes knowledge of the agent identified by the string ID;O is the deontic operator for the agent identified by ID.To represent the knowledge of an agent under the assumption of correct behaviour of another agent we use the operator KH followed by an identifier for thefirst agent,followed by another identifier for the second agent, and a formula.4.2Implementation of the algorithmFigure2lists the main components of the software tool that we have implemented. Steps2to6,inside the dashed box,are performed automatically upon invocation of the tool.These steps are coded mainly in C++and can be summarised as follows:–In step2the inputfile is parsed using the standard tools Lex and Yacc.In this step various parameters are stored in temporary lists;such parameters include the agents’names,local states,actions,protocols,etc.–In step3the lists obtained in step2are traversed to build the OBDD’s for the ver-ification algorithm.These OBDD’s are created and manipulated using the CUDD library[19].In this step the number of variables needed to represent local states and actions are computed;following this,all the OBDD’s are built by translating the1.2.3.4.5.6.7.Fig.2.Software structureboolean formulae for protocols,evolution functions,evaluation,etc.Also,the set of reachable states is computed using the operator presented in Section3.2.–In steps4the formulae to be checked are read from a textfile,and parsed.–In step5the verification is performed by implementing the algorithm of Section3.2.At the end step5,an OBDD representing the set of states in which a formula holds is computed.–In step6,the set of reachable states is compared with the OBDD corresponding to each formula.If the two sets are equivalent,the formula holds in the model and the tools produce a positive output.If the two sets are not equivalent,the tool producesa negative output.5An example:the bit transmission problem with faultsIn this section we test our implementation by verifying temporal,epistemic and deontic properties of a communication example:the bit transmission problem[5].The bit-transmission problem involves two agents,a sender,and a receiver, communicating over a faulty communication channel.The channel may drop messages but will notflip the value of a bit being sent.wants to communicate some information (the value of a bit)to.One protocol for achieving this is as follows.immediately starts sending the bit to,and continues to do so until it receives an acknowledgement from.does nothing until it receives the bit;from then on it sends acknowledge-ments of receipt to.stops sending the bit to when it receives an acknowledge-ment.This scenario is extended in[10]to deal with failures.In particular,here we assumethat may not behave as intended perhaps as a consequence of a failure.There aredifferent kind of faults that we may consider for.Following[10],we discuss two examples;in thefirst,may fail to send acknowledgements when it receives a message.In the second,may send acknowledgements even if it has not received any message.In Section5.1,we give an overview of how these scenarios can be encoded in theformalism of deontic interpreted systems.This section is taken from[10].In Section5.2we verify some properties of this scenario with our tool,and we give some quantitative results about its performance.5.1Deontic interpreted systems for the bit transmission problemIt is possible to represent the scenario described above by means of the formalism of deontic interpreted systems,as presented in[10,8].To this end,a third agent called(environment)is introduced,to model the unreliable communication channel.The localstates of the environment record the possible combinations of messages that have been sent in a round,either by or.Hence,four possible local states are taken forthe environment:,where ‘.’represents configurations in which no message has been sent by the correspondingagent.The actions for the environment correspond to the transmission of mes-sages between and on the unreliable communication channel.It is assumed that the communication channel can transmit messages in both directions simultaneously, and that a message travelling in one direction can get through while a message travel-ling in the opposite direction is lost.The set of actions for the environment is:.“”represents the action in which the channel transmits any message successfully in both directions,“”that it transmits success-fully from to but loses any message from to,“”that it transmits suc-cessfully from to but loses any message from to,and“”that it loses any messages sent in either direction.We assume the following constant function for the protocol of the environment,:for allThe evolution function for is reported in Table1.Final stateandandand orknowledgement from:.The set of actions for is:,where denotes a null action..The protocol for is defined as follows:The transition conditions for are listed in Table2.Final stateand andand and orTransition conditionand and orand andandandTable3.Transition conditions for.Faulty receiver–2In this second case we assume that may send acknowledgements without having received a bitfirst.We model this scenario with the following set of local states for:The local states“”,“”,“”,“”and””are as above;“”is a further faulty state corresponding to the fact that,at some point in the past,sent an acknowl-edgement without having received a bit.The actions allowed are the same as in theprevious example.The protocol is defined as follows:The evolution function is reported in Table4.Final stateand andand and orand andand and oris included in the downlodablefiles).The two formulae were correctly verified by thetool for,while Formula1failed in as expected.To evaluate the performance of our tool,wefirst analyse the space requirements.Following the standard conventions,we define the size of a deontic interpreted systemas,where is the size of the state space and is the size of the relations.In our case,we define as the number all the possible combinations oflocal states and actions.In the example above,there are4local states and3actions for ,5(or6)local states and2actions for,and4local states and4actions for.In total we have.To define we must take into account that,in additionto the temporal relation,there are also the epistemic and deontic relations.Hence,we define as the sum of the sizes of temporal,epistemic,and deontic relations.We approximate as,hence.To quantify the memory requirements we consider the maximum number of nodesallocated for the OBDD’s.Notice that thisfigure over-estimates the number of nodesrequired to encode the state space and the relations.Further,we report the total memory used by the tool(in MBytes).The formulae of both examples required a similar amount of memory and nodes.The average experimental results are reported in Table5.Memory(MBytes)Verification0.045sec0.05secTable6.Running time(for one formula).We see these as very encouraging results.We have been able to check formulae with nested temporal,epistemic and deontic modalities in less than0.1seconds on a standard PC,for a non-trivial model.Also,the number of OBDD’s nodes is orders of magnitude smaller than the size of the model.Therefore,we believe that our tool could perform reasonably well even in much bigger scenarios.6ConclusionIn this paper we have extended a major verification technique for reactive systems—symbolic model checking via OBDD’s—to verify temporal,epistemic,and deontic properties of multiagent systems.We provided an algorithm and its implementation,and we tested our implementation by means of an example:the bit transmission problem with faults.The results obtained are very encouraging,and we estimate that our toolcould be used in bigger examples.For the same reason,we see as feasible an extension of the tool to include other modal operators.References1.M.Benerecetti,F.Giunchiglia,and L.Serafini.Model checking multiagent systems.Journalof Logic and Computation,8(3):401–423,June1998.2.R.H.Bordini,M.Fisher,C.Pardavila,and M.Wooldridge.Model checking AgentSpeak.In Proceedings of the Second International Joint Conference on Autonomous Agents and Multiagent Systems(AAMAS’03),July2003.3.R.E.Bryant.Graph-based algorithms for boolean function manipulation.IEEE Transactionon Computers,pages677–691,August1986.4. E.M.Clarke,O.Grumberg,and D.A.Peled.Model Checking.The MIT Press,Cambridge,Massachusetts,1999.5.R.Fagin,J.Y.Halpern,Y.Moses,and M.Y.Vardi.Reasoning about Knowledge.The MITPress,Cambridge,Massachusetts,1995.6.G.J.Holzmann.The model checker spin.IEEE transaction on software engineering,23(5),May1997.7.M.R.A.Huth and M.D.Ryan.Logic in Computer Science:Modelling and Reasoning aboutSystems.Cambridge University Press,Cambridge,England,2000.8. A.Lomuscio,F.Raimondi,and M.Sergot.Towards model checking interpreted systems.InProceedings of MoChArt,Lyon,France,August2002.9. A.Lomuscio and M.Sergot.On multi-agent systems specification via deontic logic.In J.-JMeyer,editor,Proceedings of ATAL2001,volume2333.Springer Verlag,July2001.10. A.Lomuscio and M.Sergot.Violation,error recovery,and enforcement in the bit transmis-sion problem.In Proceedings of DEON’02,London,May2002.11.K.L.McMillan.Symbolic model checking:An approach to the state explosion problem.Kluwer Academic Publishers,1993.12.R.van der Meyden and N.V.Shilov.Model checking knowledge and time in systems withperfect recall.FSTTCS:Foundations of Software Technology and Theoretical Computer Science,19,1999.13.R.van der Meyden and K.Su.Symbolic model checking the knowledge of the diningcryptographers.Submitted,2002.14.J.-J.Meyer and R.Wieringa,editors.Deontic Logic in Computer Science,Chichester,1993.15.W.Penczek and A.Lomuscio.Verifying epistemic properties of multi-agent systems viamodel checking.Fundamenta Informaticae,55(2):167–185,2003.16. F.Raimondi and A.Lomuscio.A tool for verification of deontic interpreted systems./pg/franco/mcdis-0.1.tar.gz.17. F.Raimondi and A.Lomuscio.Verification of multiagent systems via ordered binary deci-sion diagrams:an algorithm and its implementation.Submitted,2004.18. A.S.Rao.AgentSpeak(L):BDI agents speak out in a logical computable language.LectureNotes in Computer Science,1038:42–52,1996.19. F.Somenzi.CU Decision Diagram Package-Release 2.3.1./fabio/CUDD/cuddIntro.html.20.M.Wooldridge,M.Fisher,M.P.Huget,and S.Parsons.Model checking multi-agent systemswith MABLE.In M.Gini,T.Ishida,C.Castelfranchi,and W.Lewis Johnson,editors,Pro-ceedings of the First International Joint Conference on Autonomous Agents and Multiagent Systems(AAMAS’02),pages952–959.ACM Press,July2002.。