Совместимость

Ведущий раздел этой статьи может быть слишком коротким, чтобы адекватно резюмировать ключевые моменты . Пожалуйста, рассмотрите возможность расширения лид, чтобы предоставить доступный обзор всех важных аспектов статьи. ( Декабрь 2016 г. )

Функциональная совместимость - это характеристика продукта или системы, интерфейсы которых полностью понятны, для работы с другими продуктами или системами, в настоящее время или в будущем, либо при реализации, либо при доступе без каких-либо ограничений. ^[1]

Хотя этот термин изначально был определен для информационных технологий или услуг системной инженерии для обмена информацией ^[2], более широкое определение учитывает социальные, политические и организационные факторы, которые влияют на производительность системы. ^[3] Следовательно, функциональная совместимость включает задачу создания согласованных сервисов для пользователей, когда отдельные компоненты технически различны и управляются разными организациями. ^[4]

Типы [ править ]

Если две или более системы используют общие форматы данных и протоколы связи и способны взаимодействовать друг с другом, они демонстрируют синтаксическую совместимость . XML и SQL являются примерами распространенных форматов данных и протоколов. Форматы данных нижнего уровня также способствуют синтаксической совместимости, гарантируя, что алфавитные символы хранятся в одном и том же формате ASCII или Unicode во всех системах связи.

Помимо способности двух или более компьютерных систем обмениваться информацией, семантическая совместимость - это способность автоматически интерпретировать осмысленно и точно обмениваемую информацию для получения полезных результатов, определенных конечными пользователями обеих систем. Для достижения семантической совместимости обе стороны должны ссылаться на общую эталонную модель обмена информацией. Содержание запросов на обмен информацией определяется однозначно: то, что отправлено, совпадает с тем, что понимается. Возможность продвижения этого результата за счет управляемой пользователем конвергенции разрозненных интерпретаций одной и той же информации была объектом исследования исследовательских прототипов, таких как S3DB .

Междоменная совместимость предполагает совместную работу множества социальных, организационных, политических и юридических лиц для достижения общих интересов и / или обмена информацией. ^[5]

Функциональная совместимость и открытые стандарты [ править ]

Функциональная совместимость подразумевает обмен между рядом продуктов или аналогичными продуктами от нескольких разных поставщиков, или даже между прошлыми и будущими версиями одного и того же продукта. Функциональная совместимость может развиваться постфактум как особая мера между двумя продуктами, исключая остальные, с использованием открытых стандартов. Когда поставщик вынужден адаптировать свою систему к доминирующей системе, не основанной на открытых стандартах, это является совместимостью , а не взаимодействием.

Открытые стандарты [ править ]

Открытые стандарты полагаются на широкую консультативную и инклюзивную группу, включающую представителей поставщиков, ученых и других лиц, заинтересованных в разработке, которая обсуждает и обсуждает технические и экономические достоинства, недостатки и осуществимость предлагаемого общего протокола. После того, как сомнения и оговорки всех членов будут рассмотрены, итоговый общий документ утверждается в качестве общего стандарта. Этот документ впоследствии публикуется и отныне становится открытым стандартом. Обычно он публикуется и доступен бесплатно или по номинальной стоимости любому желающему без каких-либо дополнительных затруднений.Различные поставщики и частные лица (даже те, которые не входили в первоначальную группу) могут использовать документ стандартов для создания продуктов, которые реализуют общий протокол, определенный в стандарте, и, таким образом, совместимы по дизайну, без какой-либо конкретной ответственности или преимуществ для любого клиента за выбор одного продукта по сравнению с другим на основе стандартизованных функций. Продукты поставщиков конкурируют по качеству реализации, пользовательскому интерфейсу, простоте использования, производительности, цене и множеству других факторов, сохраняя при этом данные клиента нетронутыми и передаваемыми, даже если он решит переключиться на другой конкурирующий продукт для бизнеса. причины.

Постфактум совместимость [ править ]

Этот раздел, возможно, содержит оригинальные исследования . Пожалуйста, улучшите его , проверив сделанные утверждения и добавив встроенные цитаты . Заявления, содержащие только оригинальные исследования, следует удалить. ( Август 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Функциональная совместимость постфактум может быть результатом абсолютного доминирования на рынке определенного продукта в нарушение любых применимых стандартов или отсутствия каких-либо действующих стандартов на момент внедрения этого продукта. Поставщик, стоящий за этим продуктом, может затем игнорировать любые будущие стандарты и вообще не участвовать в каком-либо процессе стандартизации, используя свою почти монополию, чтобы настаивать на том, чтобы его продукт устанавливал стандарты де-факто благодаря своему доминированию на рынке. Это не проблема, если реализация продукта является открытой и минимально обремененной, но она также может быть как закрытой, так и сильно обремененной (например, патентными формулами). Из-за сетевого эффектадостижение функциональной совместимости с таким продуктом является критическим для любого другого поставщика, если он желает оставаться актуальным на рынке, и труднодостижимым из-за отсутствия сотрудничества на равных условиях с первоначальным поставщиком, который вполне может увидеть нового поставщика. как потенциальный конкурент и угроза. Новые реализации часто полагаются на обратный инжиниринг в чистой комнате при отсутствии технических данных для достижения совместимости. Первоначальные поставщики могут предоставлять такие технические данные другим, часто во имя «поощрения конкуренции», но такие данные неизменно обременены и могут иметь ограниченное использование. Доступность таких данных не эквивалентна открытому стандарту, потому что:

1. Данные предоставляются исходным поставщиком на дискреционной основе, который полностью заинтересован в блокировке эффективного внедрения конкурирующих решений и может тонко изменить или изменить свой продукт, часто в более новых версиях, так что реализации конкурентов почти, но не вполне совместимы, что заставляет клиентов считать их ненадежными или низкокачественными. Эти изменения могут быть либо вообще не переданы другим поставщикам, либо переданы после стратегической задержки, сохраняя доминирующее положение на рынке исходного поставщика.
2. Сами данные могут быть обременены, например, патентами или ценообразованием, что приведет к зависимости всех конкурирующих решений от исходного поставщика и, возможно, приведет к потоку доходов от клиентов конкурентов обратно к исходному поставщику. Этот поток доходов является только результатом доминирования исходного продукта на рынке, а не результатом какого-либо врожденного превосходства.
3. Даже когда первоначальный поставщик искренне заинтересован в продвижении здоровой конкуренции (чтобы он также мог извлечь выгоду из результирующего инновационного рынка), функциональная совместимость постфактум может быть нежелательной, поскольку многие дефекты или причуды могут быть напрямую связаны с техническими характеристиками исходной реализации ограничения. Хотя в открытом процессе каждый может выявить и исправить такие ограничения, и получившаяся более чистая спецификация может использоваться всеми поставщиками, это сложнее постфактум, поскольку у клиентов уже есть ценная информация и процессы, закодированные в неисправном, но доминирующем продукте. а другие поставщики вынуждены повторять эти ошибки и причуды, даже если они могли бы разработать лучшие решения, ради сохранения совместимости. В качестве альтернативы,Можно утверждать, что даже открытые процессы подвержены давлению прошлых реализаций и несовершенным прошлым проектам и что способность доминирующего поставщика в одностороннем порядке исправлять или улучшать систему и навязывать изменения всем пользователям способствует инновациям.
4. Отсутствие открытого стандарта также может стать проблемой для клиентов, как в случае неспособности исходного поставщика исправить определенную проблему, которая является артефактом технических ограничений в исходном продукте. Заказчик хочет, чтобы эта ошибка была исправлена, но поставщик должен поддерживать это состояние неисправности даже в новых версиях того же продукта, потому что такое поведение является стандартом де-факто, и гораздо большему количеству клиентов придется заплатить цену любого нарушения совместимости, вызванного путем исправления исходной проблемы и введения нового поведения.

Правительство [ править ]

электронное правительство [ править ]

Говоря с точки зрения электронного правительства, функциональная совместимость означает возможность совместной работы трансграничных услуг для граждан, предприятий и органов государственного управления. Обмен данными может быть проблемой из-за языковых барьеров, различных спецификаций форматов и разновидностей категоризации. Можно выделить еще много препятствий.

Если данные интерпретируются по-другому, сотрудничество ограничено, занимает больше времени и неэффективно. Например, если гражданин страны A хочет купить землю в стране B, ему будет предложено предоставить правильные адресные данные. Адресные данные в обеих странах включают полное имя, название и номер улицы, а также почтовый индекс. Порядок указания адреса может отличаться. На том же языке это не препятствие для заказа предоставленных адресных данных; но преодолев языковые барьеры, это становится все труднее и труднее. Если для языка требуются другие символы, это практически невозможно, если нет инструментов для перевода.

Следовательно, приложениям электронного правительства необходимо обмениваться данными семантически совместимым образом. Это экономит время и деньги, а также сокращает количество ошибок. Области практического использования можно найти во всех областях политики, будь то правосудие, торговля или участие и т. Д. Требуются четкие концепции моделей интерпретации.

Управление рисками наводнений [ править ]

Функциональная совместимость используется исследователями в контексте управления рисками городских наводнений. ^[6]   Города и городские районы по всему миру расширяются, что создает сложные пространства с множеством взаимодействий между окружающей средой, инфраструктурой и людьми. Для решения этой проблемы и надлежащего управления водными ресурсами в городских районах необходима система системного подхода к управлению водными ресурсами и наводнениями . В этом контексте функциональная совместимость важна для облегчения системного мышления при управлении наводнениями и определяется как: « способность любой системы управления водными ресурсами перенаправлять воду и использовать другую систему (системы) для поддержания или повышения ее производительности во время события превышения уровня воды». Путем оценки сложных свойств городских инфраструктурных систем, в частности взаимодействия между дренажными системами и другими городскими системами (например, инфраструктурой, такой как транспорт), можно было бы расширить возможности всей системы по управлению паводковыми водами в направлении улучшения городских паводков. устойчивость. ^[7]

Военные [ править ]

Force interoperability is defined in NATO as the ability of the forces of two or more nations to train, exercise and operate effectively together in the execution of assigned missions and tasks. Additionally NATO defines interoperability more generally as the ability to act together coherently, effectively and efficiently to achieve Allied tactical, operational and strategic objectives.^[8]

At the strategic level, interoperability is an enabler for coalition building. It facilitates meaningful contributions by coalition partners. At this level, interoperability issues center on harmonizing the world views, strategies, doctrines, and force structures. Interoperability is an element of coalition willingness to work together over the long term to achieve and maintain shared interests against common threats. Interoperability at the operational and tactical levels is where strategic/political interoperability and technological interoperability come together to help allies shape the environment, manage crises, and win wars. The benefits of interoperability at the operational and tactical levels generally derive from the fungibility or interchangeability of force elements and units. "Technological interoperability" reflects the interfaces between organizations and systems. It focuses on communications and computers but also involves the technical capabilities of systems and the resulting mission compatibility or incompatibility between the systems and data of coalition partners. At the technological level, the benefits of interoperability come primarily from their impacts at the operational and tactical levels in terms of enhancing fungibility and flexibility.^[9]

Public safety[edit]

Interoperability is an important issue for law enforcement, fire fighting, EMS, and other public health and safety departments, because first responders need to be able to communicate during wide-scale emergencies. It has been a major area of investment and research over the last 12 years.^[10][11] Traditionally, agencies could not exchange information because they operated widely disparate hardware that was incompatible.^[12] Agencies' information systems such as computer-aided dispatch systems (CAD) and records management systems (RMS) functioned largely in isolation, so-called "information islands." Agencies tried to bridge this isolation with inefficient, stop-gap methods while large agencies began implementing limited interoperable systems. These approaches were inadequate and, in the US, the lack of interoperability in the public safety realm become evident during the 9/11 attacks^[13] on the Pentagon and World Trade Center structures. Further evidence of a lack of interoperability surfaced when agencies tackled the aftermath of the Hurricane Katrina disaster.

In contrast to the overall national picture, some states, including Utah, have already made great strides forward. The Utah Highway Patrol and other departments in Utah have created a statewide data sharing network using technology from a company based in Bountiful, Utah, FATPOT Technologies.

The Commonwealth of Virginia is one of the leading states in the United States in improving interoperability and is continually recognized as a National Best Practice by the Department of Homeland Security (DHS).^{[citation needed]} Virginia's proven practitioner-driven governance structure ensures that all the right players are involved in decision making, training and exercises, and planning efforts.^{[citation needed]} The Interoperability Coordinator leverages a regional structure to better allocate grant funding around the Commonwealth so that all areas have an opportunity to improve communications interoperability. Virginia's strategic plan for communications is updated yearly to include new initiatives for the Commonwealth – all projects and efforts are tied to this plan, which is aligned with the National Emergency Communications Plan, authored by the Department of Homeland Security's Office of Emergency Communications (OEC).

The State of Washington^[14] seeks to enhance interoperability statewide. The State Interoperability Executive Committee^[15] (SIEC), established by the legislature in 2003, works to assist emergency responder agencies (police, fire, sheriff, medical, hazmat, etc.) at all levels of government (city, county, state, tribal, federal) to define interoperability for their local region.

Washington recognizes collaborating on system design and development for wireless radio systems enables emergency responder agencies to efficiently provide additional services, increase interoperability, and reduce long-term costs.

This work saves the lives of emergency personnel and the citizens they serve.

The U.S. government is making an effort to overcome the nation's lack of public safety interoperability. The Department of Homeland Security's Office for Interoperability and Compatibility (OIC) is pursuing the SAFECOM^[16] and CADIP and Project 25 programs, which are designed to help agencies as they integrate their CAD and other IT systems.

The OIC launched CADIP in August 2007. This project will partner the OIC with agencies in several locations, including Silicon Valley. This program will use case studies to identify the best practices and challenges associated with linking CAD systems across jurisdictional boundaries. These lessons will create the tools and resources public safety agencies can use to build interoperable CAD systems and communicate across local, state, and federal boundaries.

Commerce and Industries[edit]

Information technology and computers[edit]

Desktop[edit]

The desktop interoperability (also known as interop) is a sub-section of the software interoperability. In the early days, the focus of ‘interop’ was to integrate web-applications with other web-applications. Over time, open-system ‘containers’ were developed to create a virtual desktop environment in which these applications could be registered and then communicate with each other using simple pub/sub patterns. Rudimentary UI capabilities were also supported allowing windows to be grouped with other windows. Today, the desktop interoperability has evolved into full-service interop platforms which include container support, basic exchange between web and web, but also native support for other application types and advanced window management. The very latest interop platforms also include application services such as universal search, notifications, user permissions and preferences, 3rd party application connectors and language adapters for in-house applications.

Information search[edit]

Search interoperability refers to the ability of two or more information collections to be searched by a single query.

Specifically related to web-based search, the challenge of interoperability stems from the fact designers of web resources typically have little or no need to concern themselves with exchanging information with other web resources. Federated Search technology, which does not place format requirements on the data owner, has emerged as one solution to search interoperability challenges. In addition, standards, such as OAI-PMH, RDF, and SPARQL, have emerged recently that also help address the issue of search interoperability related to web resources. Such standards also address broader topics of interoperability, such as allowing data mining.

Software[edit]

With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of exchange formats, to read and write the same file formats, and to use the same protocols. (The ability to execute the same binary code on different processor platforms is 'not' contemplated by the definition of interoperability.) The lack of interoperability can be a consequence of a lack of attention to standardization during the design of a program. Indeed, interoperability is not taken for granted in the non-standards-based portion of the computing world.^[17]

According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms, interoperability is defined as follows: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".^[18]

Note that the definition is somewhat ambiguous because the user of a program can be another program and, if the latter is a portion of the set of program that is required to be interoperable, it might well be that it does need to have knowledge of the characteristics of other units.

This definition focuses on the technical side of interoperability, while it has also been pointed out^{[by whom?]} that interoperability is often more of an organizational issue: often interoperability has a significant impact on the organizations concerned, raising issues of ownership (do people want to share their data? or are they dealing with information silos?), labor relations (are people prepared to undergo training?) and usability. In this context, a more apt definition is captured in the term business process interoperability.

Interoperability can have important economic consequences; for example, research has estimated the cost of inadequate interoperability in the U.S. capital facilities industry to be $15.8 billion a year.^[19] If competitors' products are not interoperable (due to causes such as patents, trade secrets or coordination failures), the result may well be monopoly or market failure. For this reason, it may be prudent for user communities or governments to take steps to encourage interoperability in various situations. At least 30 international bodies and countries have implemented eGovernment-based interoperability framework initiatives called e-GIF while in the United States there is the NIEM initiative.^[20] Standards Defining Organizations (SDOs) provide open public software specifications to facilitate interoperability; examples include the Oasis-Open organization and buildingSMART (formerly the International Alliance for Interoperability). As far as user communities, Neutral Third Party is creating standards for business process interoperability. Another example of a neutral party is the RFC documents from the Internet Engineering Task Force (IETF).

The OSLC^[21] (Open Service for Lifecycle Collaboration) community is working on finding a common standard in order that software tools can share and exchange data e.g. bugs, tasks, requirements etc. The final goal is to agree on an open standard for interoperability of open source ALM tools.^[22]

Java is a great example of an interoperable programming language that allows for programs to be written once and run anywhere with a Java Virtual Machine.^{[23][better source needed]} One writing a program in Java, so long as it does not use system-specific functionality, will maintain interoperability with all machines that have a Java Virtual Machine. There are many implementations of the Java Virtual Machine, such as Oracle, IBM, Android, etc... If a Java Virtual Machine is created to specification, applications will maintain compatibility because while the implementation is different, the underlying language interfaces are the same.^[24]

Achieving software[edit]

Software interoperability is achieved through five interrelated ways:

1. Product testing

   Products produced to a common standard, or to a sub-profile thereof, depend on the clarity of the standards, but there may be discrepancies in their implementations that system or unit testing may not uncover. This requires that systems formally be tested in a production scenario – as they will be finally implemented – to ensure they actually will intercommunicate as advertised, i.e. they are interoperable. Interoperable product testing is different from conformance-based product testing as conformance to a standard does not necessarily engender interoperability with another product which is also tested for conformance.

2. Product engineering

   Implements the common standard, or a sub-profile thereof, as defined by the industry/community partnerships with the specific intention of achieving interoperability with other software implementations also following the same standard or sub-profile thereof.

3. Industry/community partnership

   Industry-community partnerships, either domestic or international, sponsor standard workgroups with the purpose to define a common standard that may be used to allow software systems to intercommunicate for a defined purpose. At times an industry/community will sub-profile an existing standard produced by another organization to reduce options and thus making interoperability more achievable for implementations.

4. Common technology and IP

   The use of a common technology or IP may speed up and reduce the complexity of interoperability by reducing variability between components from different sets of separately developed software products and thus allowing them to intercommunicate more readily. This technique has some of the same technical results as using a common vendor product to produce interoperability. The common technology can come through 3rd party libraries or open-source developments.

5. Standard implementation

   Software interoperability requires a common agreement that is normally arrived at via an industrial, national or international standard.

Each of these has an important role in reducing variability in intercommunication software and enhancing a common understanding of the end goal to be achieved.

Market dominance and power[edit]

Interoperability tends to be regarded as an issue for experts and its implications for daily living are sometimes underrated. The European Union Microsoft competition case shows how interoperability concerns important questions of power relationships. In 2004, the European Commission found that Microsoft had abused its market power by deliberately restricting interoperability between Windows work group servers and non-Microsoft work group servers. By doing so, Microsoft was able to protect its dominant market position for work group server operating systems, the heart of corporate IT networks. Microsoft was ordered to disclose complete and accurate interface documentation, which will enable rival vendors to compete on an equal footing (“the interoperability remedy”). As of June 2005, the Commission is market testing a new proposal by Microsoft to do this, having rejected previous proposals as insufficient.

Interoperability has also surfaced in the software patent debate in the European Parliament (June–July 2005). Critics claim that because patents on techniques required for interoperability are kept under RAND (reasonable and non-discriminatory licensing) conditions, customers will have to pay license fees twice: once for the product and, in the appropriate case, once for the patent-protected program the product uses.

Medical industry[edit]

New technology is being introduced in hospitals and labs at an ever-increasing rate. The need for “plug-and-play” interoperability – the ability to take a medical device out of its box and easily make it work with one's other devices – has attracted great attention from both healthcare providers and industry.

Increasingly, medical devices like incubators, imaging (MRI, CT, ultrasound, and others) are driven by sophisticated software that must integrate at the point of care and with electronic systems, such as electronic medical records. At the 2016 Regulatory Affairs Professionals Society (RAPS) meeting, experts in the field like Angela N. Johnson with GE Healthcare and representative of the United States Food and Drug Administration provided practical seminars in how companies developing new medical devices, and hospitals installing them, can work more effectively to align interoperable software systems.^[25]

Railways[edit]

Railways have greater or lesser interoperability depending on conforming to standards of gauge, couplings, brakes, signalling, communications, loading gauge, structure gauge, and operating rules, to mention a few parameters. For passenger rail service, different railway platform height and width clearance standards may also cause interoperability problems.

North American freight and intercity passenger railroads are highly interoperable, but systems in Europe, Asia, Africa, Central and South America, and Australia are much less so. The parameter most difficult to overcome (at reasonable cost) is incompatibility of gauge, though variable gauge axle systems are increasingly used.

Telecommunications[edit]

In telecommunication, the term can be defined as:

1. The ability to provide services to and accept services from other systems, and to use the services exchanged to enable them to operate effectively together. ITU-T provides standards for international telecommunications.
2. The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users. The degree of interoperability should be defined when referring to specific cases.^[26][27]

In two-way radio, interoperability is composed of three dimensions:

• compatible communications paths (compatible frequencies, equipment and signaling),
• radio system coverage or adequate signal strength, and;
• scalable capacity.

Organizations dedicated to interoperability[edit]

Many organizations are dedicated to interoperability. All have in common that they want to push the development of the World Wide Web towards the semantic web.^{[dubious – discuss]} Some concentrate on eGovernment, eBusiness or data exchange in general. Internationally, Network Centric Operations Industry Consortium facilitates global interoperability across borders, language and technical barriers. In Europe, for instance, the European Commission and its IDABC program issue the European Interoperability Framework. IDABC was succeeded by the ISA program. They also initiated the Semantic Interoperability Centre Europe (SEMIC.EU). A European Land Information Service (EULIS) was established in 2006, as a consortium of European National Land Registers. The aim of the service is to establish a single portal through which customers are provided with access to information about individual properties, about land and property registration services, and about the associated legal environment.^[28] In the United States, the government's CORE.gov service provides a collaboration environment for component development, sharing, registration, and reuse and related to this is the National Information Exchange Model (NIEM) work and component repository. The National Institute of Standards and Technology serves as an agency for measurement standards.

See also[edit]

References[edit]

External links[edit]

This article's use of external links may not follow Wikipedia's policies or guidelines. Please improve this article by removing excessive or inappropriate external links, and converting useful links where appropriate into footnote references. (August 2016) (Learn how and when to remove this template message)

• "When and How Interoperability Drives Innovation," by Urs Gasser and John Palfrey
• CIMIT - Center for Integration of Medicine and Innovative Technology - the MD PnP Program on Medical Device Interoperability
• GIC - The Greek Interoperability Centre: A Research Infrastructure for Interoperability in eGovernment and eBusiness, in SE Europe and the Mediterranean
• Simulation Interoperability Standards Organization (SISO)
• Catalyst Communications
• Interoperability: What is it and why should I want it? Ariadne 24 (2000)
• Interoperability Constitution - DOE's GridWise Architecture Council
• Interoperability Context-Setting Framework - DOE's GridWise Architecture Council
• Decision Maker's Interoperability Checklist - DOE's GridWise Architecture Council
• OA Journal on Interoperability in Business Information Systems Archived 2016-10-14 at the Wayback Machine
• University of New Hampshire Interoperability Laboratory - premier research facility on interoperability of computer networking technologies
• Interoperability vs. intraoperability: your open choice on Bob Sutor blog, 6 December 2006
• La France v. Apple: who’s the dadvsi in DRMs?, Nicolas Jondet (University of Edinburgh), SCRIPT-ed, December 2006
• ECIS European Committee for Interoperable Systems
• Gradmann, Stefan. INTEROPERABILITY. A key concept for large scale, persistent digital libraries.
• DL.org Digital Library Interoperability, Best Practices and Modelling Foundations