Over the years, the U.S. Defense Advanced Research Projects Agency (DARPA) has conducted numerous prize competitions to spur innovation. A prize competition allows DARPA to establish an ambitious goal, opening the door to novel approaches from the public that might otherwise appear too risky for experts in a particular field to pursue. == Statutory authorities == In 1999, Congress provided prize competition authority to DARPA in the National Defense Authorization Act for Fiscal Year 2000 (P.L. 106–65), 10 U.S.C. § 4025, formerly 10 U.S.C. §2374a. DARPA also conducts prize competitions under the America COMPETES Act, 15 U.S.C. § 3719. == Recent prize competitions == DARPA Grand Challenge (2004 and 2005) was a prize competition to spur the development of autonomous vehicle technologies. The $1 million prize went unclaimed as no vehicles could complete the challenging desert route from Barstow, CA, to Primm, NV, on March 13, 2004. A year later, on October 8, 2005, the Stanford Racing Team won the $2 million prize during the second competition of the Grand Challenge in the desert Southwest near the California/Nevada state line. DARPA Urban Challenge (2007) required the competitors to build an autonomous vehicle capable of driving in traffic and performing complex maneuvers such as merging, passing, parking, and negotiating intersections. On November 3, 2007, the Carnegie Mellon Team won the $2 million prize, and its vehicle became the first autonomous vehicle that interacted with both manned and unmanned vehicle traffic in an urban environment. DARPA Network Challenge (Red Balloon Challenge) (2009) explored the roles that the Internet and social networking play in solving broad-scope, time-critical problems. On December 5, 2009, the Massachusetts Institute of Technology team won $40,000 by locating the ten moored, eight-foot, red weather balloons at ten places in the United States within seven hours. DARPA Digital Manufacturing Analysis, Correlation and Estimation Challenge (DMACE) (2010) was a three-month contest to showcase the potential of digital manufacturing of advanced materials. The University of California at Santa Barbara team won a $50,000 prize for crushing 180 digitally manufactured (DM) titanium mesh spheres with the most accurate predictive model of the components’ properties. DARPA Shredder Challenge (2011) was to identify and assess potential capabilities and vulnerabilities to sensitive information in the national security community. Participating teams must download the images of the documents shredded into more than 10,000 pieces from the Challenge website, reconstruct the documents, and solve the five puzzles. Of almost 9,000 teams, the San Francisco-based All Your Shreds Are Belong to U.S team won the $50,000 prize. DARPA UAVForge Challenge (2011-2012) aimed to build and test a user-intuitive, backpack-portable unmanned aerial vehicle (UAV) that could quietly fly in and out of critical environments to conduct sustained surveillance for up to three hours. The $100,000 prize was not claimed because none of the 140 teams met the technical matrix. DARPA Cash for Locating & Identifying Quick Response Codes (CLIQR) Quest Challenge (2012) explored the role the Internet and social media played in the timely communication, wide-area team-building, and urgent mobilization required to solve broad scope, time-critical problems. The challenge offered $40,000 to the first individual or team that could locate seven posters appearing in U.S. cities bearing the DARPA logo and a quick response code (QR) within 15 days. No team found and submitted all seven codes. DARPA Fast Adaptable Next-Generation Ground Vehicle (FANG) Challenge (2012-2013) was to use three competitions for the design of an infantry fighting vehicle, culminating in prototypes. In April 2013, DARPA awarded US$1 million to a three-man team during the first competition. DARPA decided not to proceed with the second and third competitions as originally planned and transitioned the technologies to the defense and commercial industry through the Digital Manufacturing and Design Innovation Institute (DMDII). DARPA Spectrum Challenge (2013-2014) sought to demonstrate how a software-defined radio can use a given communication channel in the presence of other users and interfering signals. Three teams emerged as the overall winners, winning a total of $150,000 in prizes. DARPA Chikungunya (CHIKV) Challenge (2014-2015) was a health-related effort to develop the most accurate predictions of CHIKV cases for all Western Hemisphere countries and territories between September 2014 and March 2015. On May 12, 2015, DARPA awarded $500,000 in prizes to the 11 winners of the competition during a scientific review DARPA Robotics Challenge (DRC) (2013-2015) aimed to develop semi-autonomous ground robots that could do "complex tasks in dangerous, degraded, human-engineered environments." A South Korean team won the first prize of $2 million, and two U.S. teams won $1 million and $500,000 as second and third winners. DARPA Cyber Grand Challenge (CGC) (2014 - 2016) was to “create automatic defensive systems capable of reasoning about flaws, formulating patches and deploying them on a network in real time.” The top three winners were awarded prizes of $2 million, $1 million, and $750,000, respectively. DARPA Spectrum Collaboration Challenge (SC2) (2016-2019) aimed to encourage the development of AI-enabled wireless networks to “ensure that the exponentially growing number of military and civilian wireless devices would have full access to the increasingly crowded electromagnetic spectrum.” A team from the University of Florida won the overall top prize of US$2 million at the final SC2 competition. DARPA Subterranean (SubT) Challenge (2017-2021) was to develop robotic technologies to map, navigate, search and exploit complex underground environments. The first-place winners of the system final competition and of the virtual final competition were awarded $2 million and $750,000, respectively, with multiple prizes awarded to the second and third-place winners. DARPA Launch Challenge (2018-2020) was a $12 million satellite launch challenge to demonstrate responsive and flexible space launch capabilities from the small launch providers and was to culminate in two separate launch competitions where the competitors must launch a satellite to low Earth orbit (LEO) within days of each other at different locations in the United States. The competition ended without a winner. DARPA Forecasting Floats in Turbulence (FFT) Challenge (2021) was to spur technologies that could predict the location of sea drifters or floats within 10 days. DARPA awarded $25,000 for first place, with prizes of $15,000 and $10,000 for second place and third place. DARPA Artificial Intelligence Cyber Challenge (AIxCC) (2023–2025) was a two-year challenge and asks competitors to design novel AI systems to secure critical software code on which Americans rely. The total prize money is $29.5 million. In March 2024, the Advanced Research Projects Agency for Health (ARPA-H) partnered with DARPA, contributing an additional $20 million to the competition's prize pool to address software vulnerabilities in medical devices, hospital IT, and biotech equipment. AIxCC collaborates with Google, Microsoft, OpenAI, Anthropic, Linux Foundation, Open Source Security Foundation, Black Hat USA, and DEF CON, all of which provide AIxCC with access to large language models. In August 2024, AIxCC held the semifinal at DEF CON in Las Vegas. DARPA and ARPA-H tested all 42 submissions by running them through various open-source coding projects with deliberately injected vulnerabilities and scored the tools based on their effectiveness in identifying and fixing security flaws. Seven teams, each winning $2 million in the semifinals, competed in the final round of the AIxCC at the August 2025 DEF CON conference. Team Atlanta won first place with a $4 million prize for its cyber reasoning systems, which identified and patched vulnerabilities across 54 million lines of code. DARPA Triage Challenge (2023 – 2026) aims to spur the development of novel physiological features for medical triage, with a total prize money of $7 million. In October 2024, Challenge Event 1 was held in Perry, Georgia, featuring to-scale replicas of disaster sites such as an airplane crash and Hurricane Katrina, and teams competed based on how closely their data aligned with the agency’s official data and how quickly and accurately their autonomous systems could identify individuals most urgently in need of medical care. DARPA concluded the second year of competitions and, in November 2025, named the top performers in systems and data categories, which will advance to the final 2026 competition. The DARPA Lift Challenge (2025-2026) is for participants to design unmanned aerial systems capable of carrying up to four times their own weight, with a minimum payload of 110 pounds. Acco
Software requirements
Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as: A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document A documented representation of a condition or capability as in 1 or 2 The activities related to working with software requirements can broadly be broken down into elicitation, analysis, specification, and management. Note that the wording Software requirements is additionally used in software release notes to explain, which depending on software packages are required for a certain software to be built/installed/used. == Elicitation == Elicitation is the gathering and discovery of requirements from stakeholders and other sources. A variety of techniques can be used such as joint application design (JAD) sessions, interviews, document analysis, focus groups, etc. Elicitation is the first step of requirements development. == Analysis == Analysis is the logical breakdown that proceeds from elicitation. Analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways. Requirements Triage or prioritization of requirements is another activity which often follows analysis. This relates to Agile software development in the planning phase, e.g. by Planning poker, however it might not be the same depending on the context and nature of the project and requirements or product/service that is being built. == Specification == Specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion that facilitates effective communication and change management. Use cases, user stories, functional requirements, and visual analysis models are popular choices for requirements specification. == Validation == Validation involves techniques to confirm that the correct set of requirements has been specified to build a solution that satisfies the project's business objectives, and to detect and correct errors in the requirements before implementation. == Management == Requirements change during projects and there are often many of them. Management of this change becomes paramount to ensuring that the correct software is built for the stakeholders. == Tool support for Requirements Engineering == === Tools for Requirements Elicitation, Analysis and Validation === Taking into account that these activities may involve some artifacts such as observation reports (user observation), questionnaires (interviews, surveys and polls), use cases, user stories; activities such as requirement workshops (charrettes), brainstorming, mind mapping, role-playing; and even, prototyping; software products providing some or all of these capabilities can be used to help achieve these tasks. There is at least one author who advocates, explicitly, for mind mapping tools such as FreeMind; and, alternatively, for the use of specification by example tools such as Concordion. Additionally, the ideas and statements resulting from these activities may be gathered and organized with wikis and other collaboration tools such as Trello. The features actually implemented and standards compliance vary from product to product. === Tools for Requirements Specification === A Software requirements specification (SRS) document might be created using general-purpose software like a word processor or one of several specialized tools. Some of these tools can import, edit, export and publish SRS documents. It may help to make SRS documents while following a standardised structure and methodology, such as ISO/IEC/IEEE 29148:2018. Likewise, software may or not use some standard to import or export requirements (such as ReqIF) or not allow these exchanges at all. === Tools for Requirements Document Verification === Tools of this kind verify if there are any errors in a requirements document according to some expected structure or standard. === Tools for Requirements Comparison === Tools of this kind compare two requirement sets according to some expected document structure and standard. === Tools for Requirements Merge and Update === Tools of this kind allow the merging and update of requirement documents. === Tools for Requirements Traceability === Tools of this kind allow tracing requirements to other artifacts such as models and source code (forward traceability) or, to previous ones such as business rules and constraints (backwards traceability). === Tools for Model-Based Software or Systems Requirement Engineering === Model-based systems engineering (MBSE) is the formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases. It is also possible to take a model-based approach for some stages of the requirements engineering and, a more traditional one, for others. Very many combinations might be possible. The level of formality and complexity depends on the underlying methodology involved (for instance, i is much more formal than SysML and, even more formal than UML) === Tools for general Requirements Engineering === Tools in this category may provide some mix of the capabilities mentioned previously and others such as requirement configuration management and collaboration. The features actually implemented and standards compliance vary from product to product. There are even more capable or general tools that support other stages and activities. They are classified as ALM tools.
The Synthetic Party
Det Syntetiske Parti (English: The Synthetic Party) is a political party driven by artificial intelligence (AI), founded in May 2022 in Denmark. The party aims to represent non-voters and fringe political parties while raising awareness of AI's societal role and exploring how it can be integrated into democratic processes. == Founder == The founder and continuous party secretary is Asker Bryld Staunæs, a philosopher from Aarhus University and a conceptual artist. == Main goal == The political goals have been machine learned from texts by Danish fringe parties since 1970 and represent the 20 percent of Danes who do not vote in the election. The party is synthetic; as such, many of the policies, such as universal basic income, can be contradictory to one another. == International collaborations == The Synthetic Party has signed bilateral collaboration agreements with the Finnish AI Party and AI Party (Japan) concerning the development of a global project created around artificial intelligence and politics These collaborations were expanded during the exhibition-event Synthetic Summit (28 February – 13 April 2025) at Kunsthal Aarhus, curated by Computer Lars (Asker Bryld Staunæs) on behalf of The Synthetic Party. The summit staged parliamentary scenography, performances, and computer sculptures, and invited both the public and policymakers to encounter an international line-up of AI parties and virtual politicians. Aarhus University described the event as part of Staunæs's PhD research, positioning it as an international top-meeting of virtual politicians. Participants included the Japanese AI Party, the Swedish AI Party, the Finnish AI Party, Parker Politics (New Zealand), Lex AI (Brazil), the Simiyya collective (Egypt/Sweden), the Synthetic Party (Denmark), and Wiktoria Cukt 2.0 (Poland). As part of the summit, the one-day AI World Congress was held on 1 March 2025, structured as a performative assembly where each group participated through both machinic agents and human delegates. Sessions were chaired by participating parties, with Computer Lars delivering the opening presentation. Throughout the day, contributions were synthesized into a common record using a shared AI system. The congress concluded with the adoption of the Synthetic Summit Resolution, a collectively authored treaty of algorithmic governance. Signatories included Floor Kist and Nick Gerritsen (Parker Politics), Michihito Matsuda (Japanese AI Party), Emma Bexell (Swedish AI Party), Samee Haapa (Finnish AI Party), Pedro Markun (Lex AI), Kristian T. Madsen and Michael Birkebæk Jensen (NextGen Democracy / DemAI), Asker Bryld Staunæs, Benjamin Asger Krog Møller, Caroline Sofie Axelsson, Life with Artificials (The Synthetic Party), and Piotr Wyrzykowski (Wiktoria Cukt 2.0).
Integrated Operations in the High North
Integrated Operations in the High North (IOHN, IO High North or IO in the High North) is a unique collaboration project that during a four-year period starting May 2008 is working on designing, implementing and testing a Digital Platform for what in the upstream oil and gas industry is called the next or second generation of Integrated Operations. The work on the Digital platform is focussed on capture, transfer and integration of real-time data from the remote production installations to the decision makers. A risk evaluation across the whole chain is also included. The platform is based on open standards and enables a higher degree of interoperability. Requirements for the digital platform come from use cases defined within the Drilling and Completion, Reservoir and Production and Operations and Maintenance domains. The platform will subsequently be demonstrated through pilots within these three domains. The project was a sidecar initiative for Statoil’s Global Operations Data Integration Project. This was part of a very ambitious Master Plan IT (MapIT), which also included the Real Time Visualization (RTV) tender. The RTV tender aimed to be an ontology-aware information workspace for a wide range of disciplines, as per the IO Capability Stack. Additionally, the sidecar project aimed to increase the semantic web knowledge among suppliers in the industry. This new platform is considered an important enabler for safe and sustainable operations in remote, vulnerable and hazardous areas such as the High North, but the technology is clearly also applicable in more general applications. The IOHN project consortium consists of 23 participants, including operators, service providers, software vendors, technology providers, research institutions and universities. In addition, the Norwegian Defence Force is working with the project to resolve common infrastructural and interoperability challenges. The project is managed by Det Norske Veritas (DNV). Nils Sandsmark was the project manager during the initiation and start-up phase. Frédéric Verhelst took over as project manager from the beginning of 2009. Financing comes from the participants and the Research Council of Norway (RCN) for parts of the project (GOICT and AutoConRig). == Participants == The consortium consists of the following 22 participants (in alphabetical order):
Model
A model is an informative representation of an object, person, or system. The term originally denoted the plans of a building in 16th-century English, and derived via French and Italian ultimately from Latin modulus, 'a measure'. Models can be divided into physical models (e.g. a ship model) and abstract models (e.g. a set of mathematical equations describing the workings of the atmosphere for the purpose of weather forecasting). Abstract or conceptual models are central to philosophy of science. In scholarly research and applied science, a model should not be confused with a theory: while a model seeks only to represent reality with the purpose of better understanding or predicting the world, a theory is more ambitious in that it claims to be an explanation of reality. == Types of model == === Model in specific contexts === As a noun, model has specific meanings in certain fields, derived from its original meaning of "structural design or layout": Model (art), a person posing for an artist, e.g. a 15th-century criminal representing the biblical Judas in Leonardo da Vinci's painting The Last Supper Model (person), a person who serves as a template for others to copy, as in a role model, often in the context of advertising commercial products; e.g. the first fashion model, Marie Vernet Worth in 1853, wife of designer Charles Frederick Worth. Model (product), a particular design of a product as displayed in a catalogue or show room (e.g. Ford Model T, an early car model) Model (organism) a non-human species that is studied to understand biological phenomena in other organisms, e.g. a guinea pig starved of vitamin C to study scurvy, an experiment that would be immoral to conduct on a person Model (mimicry), a species that is mimicked by another species Model (logic), a structure (a set of items, such as natural numbers 1, 2, 3,..., along with mathematical operations such as addition and multiplication, and relations, such as < {\displaystyle <} ) that satisfies a given system of axioms (basic truisms), i.e. that satisfies the statements of a given theory Model (CGI), a mathematical representation of any surface of an object in three dimensions via specialized software Model (MVC), the information-representing internal component of a software, as distinct from its user interface === Physical model === A physical model (most commonly referred to simply as a model but in this context distinguished from a conceptual model) is a smaller or larger physical representation of an object, person or system. The object being modelled may be small (e.g., an atom) or large (e.g., the Solar System) or life-size (e.g., a fashion model displaying clothes for similarly-built potential customers). The geometry of the model and the object it represents are often similar in the sense that one is a rescaling of the other. However, in many cases the similarity is only approximate or even intentionally distorted. Sometimes the distortion is systematic, e.g., a fixed scale horizontally and a larger fixed scale vertically when modelling topography to enhance a region's mountains. An architectural model permits visualization of internal relationships within the structure or external relationships of the structure to the environment. Another use is as a toy. Instrumented physical models are an effective way of investigating fluid flows for engineering design. Physical models are often coupled with computational fluid dynamics models to optimize the design of equipment and processes. This includes external flow such as around buildings, vehicles, people, or hydraulic structures. Wind tunnel and water tunnel testing is often used for these design efforts. Instrumented physical models can also examine internal flows, for the design of ductwork systems, pollution control equipment, food processing machines, and mixing vessels. Transparent flow models are used in this case to observe the detailed flow phenomenon. These models are scaled in terms of both geometry and important forces, for example, using Froude number or Reynolds number scaling (see Similitude). In the pre-computer era, the UK economy was modelled with the hydraulic model MONIAC, to predict for example the effect of tax rises on employment. === Conceptual model === A conceptual model is a theoretical representation of a system, e.g. a set of mathematical equations attempting to describe the workings of the atmosphere for the purpose of weather forecasting. It consists of concepts used to help understand or simulate a subject the model represents. Abstract or conceptual models are central to philosophy of science, as almost every scientific theory effectively embeds some kind of model of the physical or human sphere. In some sense, a physical model "is always the reification of some conceptual model; the conceptual model is conceived ahead as the blueprint of the physical one", which is then constructed as conceived. Thus, the term refers to models that are formed after a conceptualization or generalization process. === Examples === Conceptual model (computer science), an agreed representation of entities and their relationships, to assist in developing software Economic model, a theoretical construct representing economic processes Language model, a probabilistic model of a natural language, used for speech recognition, language generation, and information retrieval Large language models are artificial neural networks used for generative artificial intelligence (AI), e.g. ChatGPT Mathematical model, a description of a system using mathematical concepts and language Statistical model, a mathematical model that usually specifies the relationship between one or more random variables and other non-random variables Model (CGI), a mathematical representation of any surface of an object in three dimensions via specialized software Medical model, a proposed "set of procedures in which all doctors are trained" Mental model, in psychology, an internal representation of external reality Model (logic), a set along with a collection of finitary operations, and relations that are defined on it, satisfying a given collection of axioms Model (MVC), information-representing component of a software, distinct from the user interface (the "view"), both linked by the "controller" component, in the context of the model–view–controller software design Model act, a law drafted centrally to be disseminated and proposed for enactment in multiple independent legislatures Standard model (disambiguation) == Properties of models, according to general model theory == According to Herbert Stachowiak, a model is characterized by at least three properties: 1. Mapping A model always is a model of something—it is an image or representation of some natural or artificial, existing or imagined original, where this original itself could be a model. 2. Reduction In general, a model will not include all attributes that describe the original but only those that appear relevant to the model's creator or user. 3. Pragmatism A model does not relate unambiguously to its original. It is intended to work as a replacement for the original a) for certain subjects (for whom?) b) within a certain time range (when?) c) restricted to certain conceptual or physical actions (what for?). For example, a street map is a model of the actual streets in a city (mapping), showing the course of the streets while leaving out, say, traffic signs and road markings (reduction), made for pedestrians and vehicle drivers for the purpose of finding one's way in the city (pragmatism). Additional properties have been proposed, like extension and distortion as well as validity. The American philosopher Michael Weisberg differentiates between concrete and mathematical models and proposes computer simulations (computational models) as their own class of models. == Uses of models == According to Bruce Edmonds, there are at least 5 general uses for models: Prediction: reliably anticipating unknown data, including data within the domain of the training data (interpolation), and outside the domain (extrapolation) Explanation: establishing plausible chains of causality by proposing mechanisms that can explain patterns seen in data Theoretical exposition: discovering or proposing new hypotheses, or refuting existing hypotheses about the behaviour of the system being modelled Description: representing important aspects of the system being modelled Illustration: communicating an idea or explanation
Protocol engineering
Protocol engineering is the application of systematic methods to the development of communication protocols. It uses many of the principles of software engineering, but it is specific to the development of distributed systems. == History == When the first experimental and commercial computer networks were developed in the 1970s, the concept of protocols was not yet well developed. These were the first distributed systems. In the context of the newly adopted layered protocol architecture (see OSI model), the definition of the protocol of a specific layer should be such that any entity implementing that specification in one computer would be compatible with any other computer containing an entity implementing the same specification, and their interactions should be such that the desired communication service would be obtained. On the other hand, the protocol specification should be abstract enough to allow different choices for the implementation on different computers. It was recognized that a precise specification of the expected service provided by the given layer was important. It is important for the verification of the protocol, which should demonstrate that the communication service is provided if both protocol entities implement the protocol specification correctly. This principle was later followed during the standardization of the OSI protocol stack, in particular for the transport layer. It was also recognized that some kind of formalized protocol specification would be useful for the verification of the protocol and for developing implementations, as well as test cases for checking the conformance of an implementation against the specification. While initially mainly finite-state machine were used as (simplified) models of a protocol entity, in the 1980s three formal specification languages were standardized, two by ISO and one by ITU. The latter, called SDL, was later used in industry and has been merged with UML state machines. == Principles == The following are the most important principles for the development of protocols: Layered architecture: A protocol layer at the level n consists of two (or more) entities that have a service interface through which the service of the layer is provided to the users of the protocol, and which uses the service provided by a local entity of level (n-1). The service specification of a layer describes, in an abstract and global view, the behavior of the layer as visible at the service interfaces of the layer. The protocol specification defines the requirements that should be satisfied by each entity implementation. Protocol verification consists of showing that two (or more) entities satisfying the protocol specification will provide at their service interfaces the specified service of that layer. The (verified) protocol specification is used mainly for the following two activities: The development of an entity implementation. Note that the abstract properties of the service interface are defined by the service specification (and also used by the protocol specification), but the detailed nature of the interface can be chosen during the implementation process, separately for each entity. Test suite development for conformance testing. Protocol conformance testing checks that a given entity implementation conforms to the protocol specification. The conformance test cases are developed based on the protocol specification and are applicable to all entity implementations. Therefore standard conformance test suites have been developed for certain protocol standards. == Methods and tools == Tools for the activities of protocol verification, entity implementation and test suite development can be developed when the protocol specification is written in a formalized language which can be understood by the tool. As mentioned, formal specification languages have been proposed for protocol specification, and the first methods and tools where based on finite-state machine models. Reachability analysis was proposed to understand all possible behaviors of a distributed system, which is essential for protocol verification. This was later complemented with model checking. However, finite-state descriptions are not powerful enough to describe constraints between message parameters and the local variables in the entities. Such constraints can be described by the standardized formal specification languages mentioned above, for which powerful tools have been developed. It is in the field of protocol engineering that model-based development was used very early. These methods and tools have later been used for software engineering as well as hardware design, especially for distributed and real-time systems. On the other hand, many methods and tools developed in the more general context of software engineering can also be used of the development of protocols, for instance model checking for protocol verification, and agile methods for entity implementations. == Constructive methods for protocol design == Most protocols are designed by human intuition and discussions during the standardization process. However, some methods have been proposed for using constructive methods possibly supported by tools to automatically derive protocols that satisfy certain properties. The following are a few examples: Semi-automatic protocol synthesis: The user defines all message sending actions of the entities, and the tool derives all necessary reception actions (even if several messages are in transit). Synchronizing protocol: The state transitions of one protocol entity are given by the user, and the method derives the behavior of the other entity such that it remains in states that correspond to the former entity. Protocol derived from service specification: The service specification is given by the user and the method derives a suitable protocol for all entities. Protocol for control applications: The specification of one entity (called the plant - which must be controlled) is given, and the method derives a specification of the other entity such that certain fail states of the plant are never reached and certain given properties of the plant's service interactions are satisfied. This is a case of supervisory control. == Books == Ming T. Liu, Protocol Engineering, Advances in Computers, Volume 29, 1989, Pages 79–195. G.J. Holzmann, Design and Validation of Computer Protocols, Prentice Hall, 1991. H. König, Protocol Engineering, Springer, 2012. M. Popovic, Communication Protocol Engineering, CRC Press, 2nd Ed. 2018. P. Venkataram, S.S. Manvi, B.S. Babu, Communication Protocol Engineering, 2014.
Open Neural Network Exchange
The Open Neural Network Exchange (ONNX) [ˈɒnɪks] is an open-source artificial intelligence ecosystem of technology companies and research organizations that establish open standards for representing machine learning algorithms and software tools to enable a standard format for representing machine learning models. ONNX is available on GitHub. == History == ONNX was originally named Toffee and was developed by the PyTorch team at Facebook. In September 2017 it was renamed to ONNX and announced by Facebook and Microsoft. Later, IBM, Huawei, Intel, AMD, Arm and Qualcomm announced support for the initiative. In October 2017, Microsoft announced that it would add its Cognitive Toolkit and Project Brainwave platform to the initiative. In November 2019 ONNX was accepted as graduate project in Linux Foundation AI. In October 2020 Zetane Systems became a member of the ONNX ecosystem. == Intent == The initiative targets: === Framework interoperability === Enable developers to move machine learning models between different frameworks, which may be used at different stages of the development process, such as training, architecture design, or deployment on mobile devices. === Shared optimization === Provide a common representation that can be used by hardware vendors and other developers to apply optimizations to artificial neural network models across multiple machine learning frameworks. == Contents == ONNX provides definitions of an extensible computation graph model, built-in operators and standard data types, focused on inferencing (evaluation).. The container format is Protocol Buffers. Each computation dataflow graph is a list of nodes that form an acyclic graph. Nodes have inputs and outputs. Each node is a call to an operator. Metadata documents the graph. Built-in operators are to be available on each ONNX-supporting framework. ONNX models can be trained in a single framework, such as PyTorch or TensorFlow, and then exported to ONNX. This format allows models to be transferred from the training framework to other environments for testing or deployment. Once a model is in ONNX format, it can be executed in different runtime systems or on various hardware platforms, such as GPUs or specialized AI accelerators. Using a common format enables the same model representation to be used across multiple systems and frameworks.