Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Open-Measured-Data-Management-WG/Architecture Committee"

m (updated representatives according to general assembly)
m (updated members)
(One intermediate revision by the same user not shown)
Line 5: Line 5:
 
* Andreas Benzing, [http://www.canoo.com Canoo Engineering AG] on behalf of Daimler AG
 
* Andreas Benzing, [http://www.canoo.com Canoo Engineering AG] on behalf of Daimler AG
 
* Stefan Ebeling, [http://bmw.com BMW Group]
 
* Stefan Ebeling, [http://bmw.com BMW Group]
* Gerwin Mathwig, [https://projects.eclipse.org/projects/technology.mdmweb Daimler AG, MDM@WEB project lead]
+
* Sibylle Peter, [https://projects.eclipse.org/projects/technology.mdmweb Canoo Engineering AG, MDM@WEB project lead]
* Franz Wöhrl, [http://www.audi.com/index.html AUDI AG] on behalf of Volkswagen Group of America, Inc.
+
* Gerd Weckenmann, [http://www.audi.com/index.html AUDI AG] on behalf of Volkswagen Group of America, Inc.
 
* Stefan Wartini, [http://www.muellerbbm-vas.de Müller-BBM VibroAkustik Systeme GmbH]
 
* Stefan Wartini, [http://www.muellerbbm-vas.de Müller-BBM VibroAkustik Systeme GmbH]
 
* Jan Blockx, [http://www.siemens.com/ Siemens AG]
 
* Jan Blockx, [http://www.siemens.com/ Siemens AG]
Line 15: Line 15:
 
== Next Conference Call ==
 
== Next Conference Call ==
  
The next AC meeting will be held when needed.
+
The next AC meeting will be held after a new chairman is elected.
  
 
Topics:
 
Topics:
* Election of chairman
+
* Result of election of chairman
 +
* Migration and compatibility (ORGA-145)
  
 
= Documents =
 
= Documents =

Revision as of 03:58, 26 September 2016

Members

Speaker of the Architecture Committee: Andreas Benzing

Organization

The architecture committee has a regular conference call every three weeks. The minutes are public, but participation is limited to members of the WG and invited guests. Feel free to contact the speaker of the committee to request the discussion of architecture related topics.

Next Conference Call

The next AC meeting will be held after a new chairman is elected.

Topics:

  • Result of election of chairman
  • Migration and compatibility (ORGA-145)

Documents

Architecture Specification

The latest source of the architecture specification draft is available in the MDM@WEB architecture git repository along with a proof of concept implementation.

Compiled versions are available here: File:Architecture-specification.zip (latest version).

In addition there is a documentation on how the architecture was implemented for the first components (navigator/explorer) using a rich client. Since no MDM API was available, it was implemented against a mock implementation of the API (not the final version) and test data was shown using an ATFX-Parser (thanks for Gigatronik and Christian Rechner for providing this part).

The functional and executional view on the architecture in the web client is also available.

At the current stage, there also exists a presentation about best practices that should be followed.

Technology Proposal Guidelines

Each technology proposal handed to the AC for review should contain at least the following information:

  • Proposal: The description of the proposed technology itself
  • Priotity: The priority should be specified in the according Jira ticket to allow the AC to sort upcoming decisions.
  • Lock-In/Long-Term Availability: The proposal should must a description of long-term availability of the technology including possible vendor lock-in scenarios and community changes.
  • Operations: The impact on operations must be evaluated. The information gathered from the openMDM members should be taken into account, especially the enterprise environments.
  • Driving Requiremens: The driving requirements for the proposal must be stated. If the requirements are related to the openMDM architecture, they must be illustrated using a corresponding diagram. For other requirements, an explicit description of the relation to openMDM is required.
  • Possible Alternatives: Suitable alternatives to the proposed technology must be named. An evaluation matrix of all alternatives must be provided. If no alternatives are available, the reasons for the lack of alternatives must be described, referencing previous decisions where applicable. Addtional options should be provided by community members during review.

Presentations

Meeting Minutes

Others

Back to the top