GitHub

Project is hosted in the Eclipse organization at GitHub.

MDRM

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Draft
Background

The word risk has several definitions based on the literature perspective. It describes the impact of unfortunate events. ISO 31000:2018 Risk Management standard defines risk as the “effect of uncertainty on objectives” where an effect can be positive or negative deviation from what is expected. As for the mathematician Daniel Pernoulli defines risk as “the mathematical expectation of a function of probability of events”. Risk management is the process of identification, evaluation, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities. 

A typical approach of  Risk Management is paper-based defined in a form of word documents and spreadsheets that describe the process of evaluating the risk of assets, threats and treatments. This may cause confusion in analyzing the consequnces and treatments, lack of clarity, and subject to differing interpretations stakeholders. In this prject, a model-driven approach to generate risk managment models, augmented with quantitative attrbutes such as assets, threats, existng controls, consequnces and valenurables. 

Scope

 

The project will automate the process of risk management, that includes the risk assessment, analysis and treatment. It will also provide the users with the syntax to build the textual model, and that meta-object to build the graphical model.

Description

The proposed project is a model-driven risk managment that will be used to provide and automate the exeution of  a textual and graphical medels models for the process of risk manegment phases:

  1. The identification phase is used to list all potential risks in the form of scenarios. The result is the “Risk Catalog” commonly known as hazard list.
  2. The risk analysis phase involves developing an understanding of the risk. Risk analysis provides an input to risk evaluation and to decisions on whether risks need to be treated.
  3. The risk evaluation phase is used to assist in making decisions, based on the outcomes of risk analysis, about which risk need treatment and the priority for treatment implementation.
  4.  The risk treatment phase involves selecting one or more options for modifying risks and implementing those options.
  5. In the risk acceptance, the risk treatment plans should describe how the risks will be treated to meet the risk criteria for risk acceptance.

Figure 1. Risk Management Process

Risk Management Modeling

Risk management can be represented using graphical modeling and (or) textual modeling. Graphical modeling a visualization of an idea and is used to simplify the details and present it in understandable abstract way. In order to generate a graphical model, metamodel is used to define the model elements and the relationships between them. 

The textual modeling can be represented in serval formal and informal format. The most common textual modeling is using the XML format. Using domain specific language (DSL) is another approach  for generating textual model. A domain-specific language is a computer language specialized to a particular application domain.

    • Risk Management Metamodel

Figure 2. describes a part of Risk Management metamodel, where the model elements: Asset, Existing control, Threat, Vulnerable, and Consequence with their relationships. 

Figure 2.Initial metamodel of Risk Management

    • Domain-specific Language of Risk Management

In the DSL approach, a language syntax is created using the elements of the risk management such as, Asset, Existing control, Threat, Vulnerable, and Consequence. The syntax is then is used to build and execute different scenarios of risk management.  

Risk management modeling time frame

There are three types of RM modeling time frames: 

  1. The Used-to-Be modeling which defines the design of a risk management that was evaluated in the past. 
  2. The AS-Is modeling which defines the design of risk management that is running currently.
  3. The To-Be modeling which defines the design of software system that will be deployed in the future.
Why Here?

The project is a model-driven risk management approach that is used to model the risk management process and automate the execution of  identification, analysis, evaluation and treatment of the expected risks. This will improve results of the risk menegement process and represnts the risk modeling in a formal way.

Future Work

Activity     
Expected Period   

Creating the research team,, gathering, discussions, …
1 month

Data collection, Literatures
1 – 4 months

Analyzing RM process
4 months

Proof of concept/Prototyping
1 – 4 months

Design: Modeling, Meta model
4 months

Design: Behaviour modeling
4 months

Development: Legacy layer, services, plugin
10 months

Development: Domain specific language,  xtext plugin, EMF, syntax tree
10 months

Development: Graphical modeling, graphical features, logs, reports
10 months

Model validation and verification using the developed application
6 – 9 month

 

Initial Contribution

The implementation has not been started yet. We initially will produce the metamodel of the model elements using EMF for the graphical modeling.  We will also used the xtext to produce the syntax of the DSL.

Source Repository Type

Eclipse AVSys

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

Autonomous driving research involves cooperation between engineers across fields, from control systems to machine learning. However, currently no commercial tool provides a full-stack solution for a self-driving vehicle development. Eclipse AVSys aims to provide an easy-to-use tool to speed up the autonomous driving development process. Eclipse’s customizable user interface, support for integration of new features, and strong community, make it the best starting point for our project.

 

Eclipse AVSys is an end-to-end design tool covering both hardware and software modules of an autonomous car. Using the model-based design methodology, users can describe the autonomous driving system as a block diagram. There, individual modules of the car are mapped to separate blocks. Relationships between modules are represented by linkages between blocks. 

After the system model is fully defined, a user only needs to write code for individual modules, without having to care for the overall source code structure, dependencies or build mechanisms. 


<A conceptual overview of Eclipse AVSys>

A common autonomous driving platform consists of a target vehicle, a sensor suit, and a processing unit, such as NVIDIA embedded board, running the Linux operating system with the Robot Operating System (ROS) middleware. Note that apart from the algorithm implementation, everything else is taken care of by the Eclipse AVSys.

Scope

The goal of Eclipse AVSys is to provide the necessary tools to easily model algorithms and hardware components (such as sensors and actuators) for autonomous driving:

  • Graphical editor with block diagram environment for the ROS model-based design of autonomous driving systems
  • Customizable templates of common autonomous driving systems 
  • Automatic ROS source code generator
  • Source code editor synchronized with a model specification and its graphical representation
  • Source code and model validation tools
  • ROS build automation tools that create and builds ROS packages (local or remote)
  • ROS diagnostic tools and parameter tuning 

     
Description

Eclipse AVSys adopts the model-based design methodology to describe an autonomous driving system. Using blocks and lines, users create a block diagram of the entire system, and based on it OSCAR IDE generates a ROS package and handles all dependencies. Finally, Eclipse AVSys builds the generated package on a target device and creates ready-to-launch executable ROS nodes.

Technical details: 

  • ROS-based system can be viewed as a graph, where nodes are computational processes that communicate with each other by passing messages through topics with publish/subscribe semantics. 
  • In a block diagram, nodes and topics are represented by blocks, and the message passing interface is represented by connections between blocks. 
  • Nodes and topics are defined as classes using EMF (Eclipse Modeling Framework). 
  • GEF (Graphical Editing Framework) is used to easily make and edit instances of defined classes. 
  • The actual visual representation of the classes is shown using Draw2D.

     

<A block diagram representation of a sample autonomous driving system>

The development process can be divided into the following steps:

  1. The graphical editor provides a drag-and-drop interface for creating instances of ROS publisher/subscriber nodes and topics. 
  2. The model description is saved as an XML (Extensible Markup Language) file, from which the skeleton code is generated. 
  3. Skeleton code of each module can be modified in the source code editor. All changes are simultaneously reflected in a model description and its graphical representation.
  4. Build automation tools generate a ROS package in compliance with the ROS Filesystem and transfer it to the target’s workspace directory via FTP (File Transfer Protocol). It checks for dependency issues, handles them, and builds the package.

     
Why Here?

Most common autonomous driving systems are implemented on top of ROS. Eclipse is the major IDE used by Linux developers, and It is also widely used by the ROS community.  Eclipse provides a customizable user interface, facilitates integration of new features, has several fundamental modelling project, and a lovely community. Therefore, it was a natural choice to implement Eclipse AVSys as an Eclipse extension.

Project Scheduling

The alpha version includes basic system modeling, code generation, and build automation with remote deployment; and it is already available. A public beta release with a graphical editor and a source code editor will be available soon. Features such as source code and model synchronization/validation will be developed later on. More customizable templates will be added along the way.

 

Future Work

Our community efforts will include:

  • Encouraging the college students (Seoul National University) and laboratories to use Eclipse Autonomous Driving
  • Providing detailed documentation and instruction manual 
  • Writing papers about our contributions and attending conferences
  • Hosting workshops and demo sessions

In the future we will implement more ROS-related features such as custom message generation, request/reply interaction through “services”, saving and playing back data with “bags”, diagnostics and parameter tuning.

 

Project Leads
Interested Parties
  • Advanced Automotive Research Center at Seoul National University
  • Institute of Computer Technology at Seoul National University
  • Institute of Information & Communications Technology Promotion (IITP)
  • Next-Generation Information Computing Development Program at National Research Foundation of Korea (NRF)
  • Korea Ministry of Science and ICT (Information & Communications Technology)

     
Source Repository Type

This is a very interesting new project in the Eclipse Eco-System. itemis is very interested in the concepts and current status - going to try this out after Christmas.

It also seems that there are synergies with the (emerging) openADX group. Did you already have a look at that?

Andreas

vidge

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Background

It would be good if visual forms for editing ojects would be  created automatically with idebtical views, borders, gaps and binded with edited objects .

Scope

Automated creation of visual elements for UI

Description

The project for automatically building an forms, tables and so on for business applications with standartized UI. When you building business application may be a big amount types of objects should be viewed or edited by customer in different contextes and for avoid creation of many composites .  

Why Here?

It use RCP with plugin architecture and may be make such kind of applications more common and easily created for beginners. And increase time for creation of complicated business applications.  I want to see fresh look on it. Some discussions.

Project Scheduling

Initial contribution may be right now.

Future Work

Now is realized only plain building of a forms, may be it need more complicated build structures.

Project Leads
Committers
Initial Contribution

All was written by me. No third-party libraries.

Source Repository Type

Elbfisch

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Draft
Background

Embedded PC systems are increasingly being implemented in automation technology, encouraging the design of object-orientated software development processes, a step which is long overdue. To assist with this, Elbfisch offers a runtime environment and a canon of basic functions that allow complex automation tasks to be implemented on inexpensive hardware platforms in Java.

Scope

Elbfisch offers a runtime environment and a canon of basic functions that enable the team-based development of object-orientated automation applications when used in conjunction with common open-source products (such as the integrated development environments ‘Netbeans’ and ‘Eclipse’), Linux as operating system and ‘git’ as distributed version management system. Java is used for the programming.

Description

Elbfisch offers a runtime environment and a canon of basic functions that enable the team-based development of object-orientated automation applications when used in conjunction with common open-source products (such as the integrated development environments ‘Netbeans’ and ‘Eclipse’), Linux as operating system and ‘git’ as distributed version management system. Java is used for the programming.

Why Here?

We are now handing over our project to the open-source community. We are doing this with gratitude to the many people and businesses who have been sharing their knowledge and products with others for years. We have been using open-source products ourselves for many years. The time has now come for us to make a large part of our knowledge available to the community. We hope that others find this useful – and that it contributes to peace in the world. The latter much less through the content, but more through the way in which people work together on this project – with mutual respect, with the necessary regard for the perspectives of others and with recognition of every person’s wish to use their work to make the world a better place – each providing according to their ability, with the dedication they are individually prepared to invest, regardless of their background or religion. Elbfisch has emerged from our professional work on a variety of projects and covers a range of functions that we consider useful for our particular purposes. We hope that Elbfisch will now grow beyond this scope, enriched by new perspectives, with added functions that will broaden its range of applications.

Project Scheduling

The first robust contribution can be done as soon as the project is opened. A complex package of stabil code is already available

Future Work

Distributed Elbfisch: Make Elbfisch applications run on multiple nodes seamlessly

Enhance the vioss (versatile IO subsystem) by drivers for profinet, EthernetIP, EtherCat and other industrial busses

Implementing a graphical editor (as a plugin of the Eclipse IDE) to design modules and the connecting them over signals

Committers
Initial Contribution

see https://www.elbfisch.org

Source Repository Type

Eclipse UPM

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Working Group
Proposal State
Created
Background

Current day computing systems and devices distinguish themselves from past generation systems through autonomy, less user intervention. While the emergence of autonomous systems may be less relevant in the workstation space, due to the nature of computing on such systems, it is significant in the growth of Internet of Things (IoT) devices. Regardless of the use case, autonomous systems surface, from basic process automation to smart decision making systems, with the latter expressed as artificial intelligence (AI) or machine learning (ML). The current crop of single board computers (SBCs) running Linux* distributions generally show the benefits of deploying such algorithms. Often these SBCS support acceleration cards when additional performance is required. Most importantly, the boards connect to the sensors and actuators that produce the required data needed in developing smart IoT devices and solutions.

Application developers encounter difficulty in harvesting meaningful sensor data. In general, as the complexity of the sensing or actuating device increases, the number of steps required to obtain data readings increases. Peripherals directly connected to the system follow vendor specifications for basic I/O and bus level transactions. Dealing with wireless sensors is a twofold issue. First, support must exist in the system for the modem or radio implementing the technology. Second, the system must expose a sensor data collection interface at a software level, using the stack or protocol associated with the technology. In practice, support manifests as an API abstraction layer or the showcase of usage through clear device-specific examples.

The number of devices available nowadays is astounding, with tens of thousands of devices made available through popular suppliers, manufacturers, and vendors. These sensors fall within multiple well-defined categories that in some cases have been standardized for specific application areas or industries. The standards usually specify the sensor data formats and often leave the implementation choice to the developer, who is responsible for interfacing with the sensor devices and creating support for common, legacy networks.

For OEMs, ODMs, and established consumer products, firmware and system drivers offer sensing device access. However, this support results in rather slow turnaround in the operating system (OS) realm and does not address development difficulties around building new or custom IoT systems and solutions.

These problems give rise to a need for an abstraction layer for sensor data access that can simplify the developer effort required and reduce implementation time at all stages of an IoT product, from prototyping to deployments. An abstraction layer could speed up commercial/industrial application development.

Scope

Useful Packages for MRAA (UPM) is a user space collection of sensor and actuator libraries written in the C/C++ language. The Eclipse UPM project abstracts implementation details for reading sensor data and writing actuator commands through the use of consistent APIs and function names. The project focuses on multiple key features:

  • Standardization of sensor classes: UPM standardizes sensor and actuator APIs based on type in order to create consistency between devices and vendors. The meaningful sensor data make it easy to consolidate data readings into other standardized frameworks and services.
  • Portability and scalability: Applications using the UPM libraries are portable across any MRAA supported platform offering the same I/O capabilities with little or no changes required. UPM promotes scaling to different IoT systems if computational requirements for the application change.
  • Industrial sensor and protocol support: UPM provides rich device and API abstractions for multiple industrial and wireless protocols such as BACnet*, Modbus*, CAN bus*, LoRa*, Zigbee* and Z‑Wave*. Nearly half of the devices currently on the UPM list are complex industrial-rated sensors, actuators, and radios.
  • Solution design reliability: The UPM library doesn’t lock down application development to a single vendor for popular sensor types. When multiple vendors provide the same type of sensor, the generic UPM interfaces enable hardware replacement with little or no API changes.
  • Device utilization examples: Every sensor driver in the UPM library comes with at least one usage example. They are generally provided for all the supported languages. Examples showcase initial device configuration and calibration where applicable.
Description

IoT is a multi-faceted topic, seen by many as a much-needed redefinition of embedded computing. The efficiency and performance of current CPUs, along with a decreasing footprint, enable broader products and solutions across multiple domains, such as home, industrial automation, environment, agriculture, transportation, safety, security, control systems, robotics, wireless sensor networks, and wearables. Sensing devices manifest in various categories and applications. They are very easy to obtain, and they interface to open-chassis IoT boards or even I/O rich workstation systems. However, application developers and solution architects encounter unnecessary difficulty when programming these devices. Developers must consult vendor specification sheets and comprehend intricate protocols to read or write data to sensor devices in the absence of device driver support in the OS. This added burden results in multiple system level calls to different I/O protocols. It requires access to fast mathematical and utility functions that help convert readings to meaningful sensor data. To address the developer experience (DX) problem, the MRAA project provides easy platform-independent I/O access from the application level for Linux* IoT boards.

The Eclipse UPM project builds on the solutions of MRAA. While the MRAA project provides an abstraction layer for several IoT platforms, offering developer access to the physical pins and buses, UPM supplies developers with C/C++ sensor libraries with bindings to Java*, JavaScript* and Python*. UPM makes it easier to interface with the sensors bundled with the Intel® IoT Developer Kits and extends the MRAA library. The UPM sensor libraries use MRAA I/O classes in order to expose an API abstraction that simplifies the interaction between developers and peripherals. The UPM APIs provide consistent, standardized access to the supported devices with over 400 different sensors, actuators and radio modules currently supported.

An example illustrates the application of UPM. Imagine a design that requires a temperature and humidity sensor. UPM supports dozens of such devices, offering multiple connectivity options to the system, either directly through I/Os or wirelessly. This creates plenty of design choices. Once the application is developed, the code looks similar regardless of the sensor chosen. The task of reading temperature and humidity data remains identical, using the same consistently named function calls. The implementation and underlying sensor data access may vary based on the I/O type used, but the UPM APIs remain the same. This is the value added by the UPM abstraction. Furthermore, if the sensor part needs to change at a later stage in the design, the API standardization ensures that application changes remain minimal, leading to product reliability in the long run when components or suppliers may change.

When the UPM project started, the goal was to provide easy access to the most popular maker and hobbyist grade devices in the market. These are common types of sensors and actuators encountered at many IoT-oriented gatherings and events. Quickly the project started delivering on its goal and enabled hundreds of devices, some of which were generic in nature and design. Supporting these generic devices led to virtually supporting thousands of similar or related parts across vendors. Some of the first vendors in this category were Adafruit*, SparkFun*, Seeed Studio*, and DFRobot*. In many cases maker-oriented sensor breakout boards include ICs that have commercial or industrial variants. This allows for quick prototyping and an early start on application development as well as design validation well before a commercial product is finalized.

Recently, the UPM project has aimed its focus on the more specialized devices typically found in commercial and industrial deployments. These include various controllers and actuators, high precision and ruggedized sensors, along with several established and emerging radio devices or M2M protocol interfaces in use throughout IoT deployments worldwide. For instance, UPM saw plenty of adoption for IoT projects requiring LoRa* or 4G LTE connectivity, providing the opportunity to create a common interface for radio devices and modems. At this level, standardization is critical, since many established protocols and frameworks are already in use. The UPM project adds the needed abstraction to facilitate development time with these technologies. Some of the IoT chip manufacturers with devices supported by the UPM project include Bosch*, STMicroelectronics*, Honeywell*, Semtech*, Microchip Technology*, Maxim Integrated*, NXP Semiconductors*, Measurement Technologies*, Silicon Labs*, Analog Devices*, Aeotec*, Telit Communications*, Veris Industries*, Comet*, Omega*, and several others. Protocols and technologies supported include Modbus*, BACnet*, CAN bus*, WiFi*, BLE*, LoRa*, Zigbee*, Z‑Wave*, NFC*, GPS*, GPRS*, 4G LTE*, and LiDAR*, with planned support for others. For standards that are higher up the application stack, the project provides several integration examples that use UPM within OPC-UA or OCF (e.g., IoTivity*) solutions.

Find a comprehensive summary of UPM at Bring Your IOT Products to Life.

Figure 1. High-level layout of the UPM project.

As Figure 1 shows, the scope of the UPM project is vast and diverse. In order to help organize the various sensor and actuator types the UPM project recently introduced a highly flexibly sensor specifier based on JavaScript* Object Notation (JSON). This feature allows vendors to provide detailed information about the part, technical specifications, limits, links to reference documentation, and more. The field values can be exposed back to the developer through the UPM APIs to make decisions at runtime. They are also used by the upm-site project to generate the UPM sensor catalogue which helps solution architects choose the right components during the design phase. The project was created with an open-source mindset. OEMs. ODMs, and contributors benefit from a sensor template that generates code stubs, speeding up the process of a new sensor submission. On the Intel® Developer Zone website, Technical IoT Webinars explain how the UPM project is designed and used as well as how it can be extended.

A hard build and run-time dependency exists between the MRAA and UPM projects. The UPM project has few dependencies on other system packages, the most notable being the SWIG source translation framework. SWIG is necessary if bindings for other supported languages are desired. Other 3rd party library build dependencies are reflected at a module level and are optional. The supported Operating Systems are:

  • Standard Linux* Distributions: Fedora*, Debian*, Ubuntu*, Ubilinux*, Arch Linux*, OpenSUSE*
  • Embedded Linux* Distributions and Projects: Yocto Project*, OpenEmbedded, 01.org, Wind River Linux*, Wind River Pulsar Linux*, Android Things*
  • Real-time Embedded OS: Zephyr*
  • Windows*: Only using Docker* containers and the mock platform

Contributions are checked through the use of the Travis CI system, unit testing, and static code analysis. Packaging is done on demand on stable releases only. The community maintains most of the distribution channels for the supported OSs listed above.

Code contributors must provide examples, as a minimum requirement for valid code contributions, for every sensor or actuator library that is added to the UPM project. They are also used in the validation of the devices, and in most cases, supply developers with an easy to understand use case. When relevant, examples also include device calibration information or showcase configuration options. Multiple advanced examples based on the UPM project exist as full end-to-end open-source reference implementations. These implementations, part of the Intel® IoT Developer Kit, interweave numerous IoT frameworks, bringing them together in a solution with real world applications.



The documentation pages for the UPM project are customized, and there are two auto-generators associated with the project. A Doxygen* system generates API documentation in all supported languages based on code comments and special sensor tags that help group sensors by categories. The second documentation source is a GitHub* Pages website used as the main landing site for the project. This relies on the JSON sensor specification files to provide an open source, catalog style website template for sensor and actuator manufacturers to freely customize to their end user needs.

Figure 2. UPM integration with the Eclipse IDE.

A proven strong integration point for the UPM project is with the Eclipse* IDE. Used by Intel® System Studio, the UPM sensor libraries offer developers the ability to quickly add or remove components from the supported libraries to their current C++ or Java* IoT project. The documentation pages, sensor images where available, manufacturer and vendor product links, technical datasheets, and examples quickly become available through the Sensor Support tab in the Eclipse* IDE. Behind the scenes, automation updates projects settings for developers based on their selections, and the view is dynamically generated from the latest stable published version of the project.

Over the course of 2017, the project saw over 18K unique visitors and approximately 6K unique downloads according to GitHub* metrics. Good adoption occurred internally at Intel and externally by key companies and frameworks, such as IBM* (node-red), Linaro*/ARM* (96boards), Google* (Android Things*), Emutex* (Ubilinux*), Phytec*, GE*, Technexion*, Qualcomm*, STMicroelectonics*, u-blox*, Honeywell*, Siemens* (IOT2020), Mediatek*, and many others.

The project is still under active development by Intel and the developer community. There is a tight integration with the IoT application developer workflows and the sensor explorer in Intel® System Studio. UPM is also a key component of the OS images provided for IoT Developer Kits.

*Other names and brands may be claimed as the property of others.

Why Here?

We believe the UPM project exhibits great potential for integration with the Eclipse Kura* project and it would be a suitable choice for providing sensor and actuator access to end users. There is good synergy with multiple Eclipse* IoT projects such as Eclipse Mosquitto*, Eclipse Paho*, Eclipse Milo*, and other M2M projects. In fact, several Intel® IoT Developer Kit demos use UPM and the Eclipse* MQTT frameworks for aggregating sensor data across the web. Combined, they provide the ultimate IoT toolbox for end users to develop new end-to-end IoT solutions or extend existing ones.

Furthermore, there is a good integration between UPM and the Intel® System Studio, a free product that integrates multiple Intel® tools and libraries with the Eclipse* IDE. The UPM library covers sensors and actuators from numerous device manufacturers. The Eclipse Foundation* would encourage vendor neutrality and act as an arbiter during further development of the project.

Figure 3. Sensor framework.

Project Scheduling

During the initial phases, the project pushed stable iterations of the framework to the general public at a fast pace, as new features and bug fixes were constantly becoming available. Currently, the release cadence has settled at two major releases per year, which include community contributions and fixes along with planned features and milestones from the project’s roadmap.

Future Work

Library development plans for the upcoming quarters are illustrated in Figure 4.

Figure 4. Future UPM development.

Intel plans to continue submitting code improvements for the sensors bundled with the Intel® IoT Developer Kit. Future releases may involve these features:

  • More standardized interfaces: Over several past months, the UPM project focused on delivering an enhanced set of refinements to the APIs and more generic sensor and actuator support within the APIs. The current number of interfaces will extend from 10 to approximately 30. Adding these to the project’s codebase will increase the likelihood of a stable 2.0 release.
  • New industrial protocol support: For aiding industrial and commercial development with UPM, several examples of interaction with the open62541* framework have been developed and included. The examples can be used as means for adding an OPC-UA utility class to UPM. This example or a potential integration with Eclipse Milo* can enhance standard support directly from the UPM project. Upon completion, new protocol support should follow to help integrate with more existing IoT solutions.
  • Generic abstraction for modems and radios: The project is investigating a more generic interface for radio and modem devices, as the ones currently supported by the project are rather custom. This along with the potential of adding some abstraction to PLC devices is planned following the next major release.
Initial Contribution

UPM latest source code base as available at https://github.com/intel-iot-devkit/upm.

UPM latest sources for the https://upm.mraa.io GitHub* Pages website: https://github.com/intel-iot-devkit/upm-site.

Intel® owns the copyright on approximately 90% of the library’s functional source code. This excludes 3rd party modules, collateral, integrations, tools and other supporting files that are included with the project.

The project includes 3rd party content under the following associated licenses:

  • Adafruit* Sensor Board Image License
  • DFRobot* Images License
  • Seeed* Sensor Image License
  • Creative Commons Attribution 2.0
  • Boost Software License 1.0
  • BSD 2-clause "Simplified" License
  • BSD 3-clause "New" or "Revised" License
  • MIT License
Source Repository Type

Eclipse MRAA

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Working Group
Proposal State
Created
Background

Integrated circuits (ICs) are a very important component of many modern-day devices. Current devices contain controllers and component ICs that communicate with each other with various methods and protocols. In the past these custom-made electronic components required highly specialized knowledge to produce and use. With the relentless push of very-large-scale integration (VLSI) technology, the cost of electronics plummeted, and with open-source development, software availability became ubiquitous. These two phenomena–low cost hardware and open-source software--have given rise to the maker movement that is fueling the rise of Internet of Things (IoT) in which everything is smart and connected.

With the promise of IoT, both established players and new startups are entering the market at a torrid pace with new product announcements. If fact, the amount of device diversity currently seen at the edge is unprecedented, and the applications seem limitless. These devices create massive opportunities in areas such as smart buildings and cities, automotive applications, intelligent vending and retail, manufacturing and industrial processes, biomedical industries, agriculture, environment monitoring, security, and many other verticals.

Microcontrollers (MCUs) like Arduino*, a de facto standard in the IoT space for years, have limited compute power. Many MCUs require programming on bare metal or a real-time OS. Newer products such as Raspberry Pi*, Intel® IoT Developer Kit boards, Linaro 96boards*, and Nvidia Jetson* exhibit more compute power and run on standard Linux* distributions. These products provide the flexibility of programming in an operating system like Linux* with I/Os similar to those of MCU, which increases ease of use.

Most of the aforementioned platforms come as single board computers (SBCs) that interface to peripheral devices through expandable daughter cards, usually referred to as shields, and exposed I/O pins. A variety of protocols are also made available, such as SPI, I2C, PWM, UART, etc. Unfortunately, there is no standard describing how the I/O pins are labeled and programmed, making development a more difficult task. We created the MRAA cross-platform, cross-OS library to abstract the details of I/O pin and bus mappings and simplify the level of effort and understanding required of IoT developers.

Scope

Eclipse MRAA (pronounced em-rah) is a low-level library written in the C/C++ language. MRAA abstracts the details associated with accessing and manipulating the basic I/O capabilities of popular IoT platforms and boards and presents a single, concise API delivering the following architectural features:

  • Physical Pin Mapping: MRAA provides clear and consistent API function calls that match the corresponding physical pin labels on supported IoT boards.
  • Kernel to User Space I/O Abstraction: MRAA serves as a translation layer on top of the Linux* I/O facilities. Although Linux* provides a fairly rich infrastructure for manipulating GPIOs and standard bus protocols, it does so at the kernel level. This presents difficulty for developers not experienced with device drivers, and it does not promote user-space rapid prototyping.
  • I/O Expansion: MRAA provides access to I/O expanders and Arduino* MCUs, via Firmata*, connected to a Linux* host running MRAA, using the same API classes found on regular boards. The MRAA project refers to these expanders as subplatforms, and the application runs on the Linux host.
  • Portability: Applications developed with the MRAA library can be ported to other supported boards if the same type of I/O exists on the new target. Furthermore, the C APIs simplify portability between Linux* boards and MCUs running Zephyr* RTOS through the use of the ZMRAA project which provides a near one-to-one mapping for the API calls.

NOTE: Although MRAA can be used to write platform-independent code, developers are still responsible for ensuring that code is robust enough to run on various target platforms and accommodate their specific limitations.

Description

Conceived in 2014, the Eclipse MRAA project aimed to deliver a high-level, easy-to-use set of APIs for I/O access on Linux* boards and systems, similar to Arduino* offerings for MCU boards. At the time, the project targeted support for platforms such as Intel® Galileo, Intel® Edison and Raspberry Pi* boards, highly popular among IoT enthusiasts and makers. Over time, the project evolved substantially and won the appreciation of multiple IoT communities resulting in a number of new board and feature additions. In fact, the project’s success prompted Arduino* to adopt the use of the library in their Arduino Create* cloud-based IDE in order to target x86 IoT platforms.

Development on boards and kits in Linux* environments continues to present issues in key areas: access of I/O in a platform-independent manner, portability from platform-to-platform, and consistency from revision-to-revision.

Here is a detailed look at each issue:

  • Access of I/O in a platform-independent manner:  Kernel-level abstractions are low level and can be difficult to use for inexperienced developers. The Linux* kernel exposes the I/O interface through sysfs classes or device nodes. Depending on the implementation, the details can vary from one platform to another quite drastically. However, users expect to be able to use the I/Os at a much higher level of abstraction. For example, in order to initialize i2c bus on the Intel® Edison board, the following steps are needed:
    1. Set Tristate to 0
    2. Set GPIO14 to input
    3. Set GPIO165 to input
    4. Set GPIO236 to output and disable
    5. Set GPIO237 to output and disable
    6. Set tristate to 1
    7. Set GPIO213 to input
    8. Set GPI212 to input
    9. Change pinmode for pin27
    10. Change pinmode for pin28

These details vary from one board to another and among different revisions of the same board.

  • Portability from platform-to-platform: In some situations, usually buses, device drivers provide access to I/O. Configuration of these drivers is done through Device Trees (ARM*) or ACPI tables (x86) and is usually provided by the vendor as part of the BSP. However, there are no set standards for exposing the capabilities of the underlying platform through device drivers. Consequently, developers make choices suitable for the particular platform. This leads to APIs that are not uniform across platforms and creates the need for customization of drivers for sensors connected to these platforms.
  • Consistency from revision-to-revision: A development board and the SoC on the board typically undergo revisions either to add new features or to fix bugs. In that process some changes to the I/O interfaces creep in – typically the I/O pin numbering may change. Certain steps needed to enable the I/Os can change or become unnecessary.

Using system classes and devices for GPIO and bus access from software is usually not straightforward in Linux*, since the OS numbering scheme does not match the labeling on the board. MRAA presents a façade which makes the relationship between I/O and the hardware more intuitive to developers. Here are some example class and device paths on a typical board.



To overcome the lack of standards for exposing I/O on different maker and SBC platforms, we released the MRAA project, a C/C++ library with bindings to Java*, JavaScript* and Python* to interface the I/O on the Intel® IoT Developer Kit boards, Raspberry Pi*, and other platforms. With a structured and consistent API in which port names and numbering match the board, MRAA does not tie developers to specific hardware. With board detection done at runtime, developers create portable code that will work across the supported platforms. The main I/O API classes supported by MRAA are GPIO, AIO Analog*, PWM, SPI, I2C, and UART. Additionally, the library can also interface with 1-Wire*, Firmata*, IIO, and named LED devices.  See the block diagram in Figure 1 to understand where MRAA fits in a typical software stack.

Figure 1. Hardware Abstraction MRAA

MRAA makes it easier for developers and sensor manufacturers to map their sensors & actuators on top of supported hardware and allows control of low level communication protocols from user-space using high level languages and constructs.

MRAA is supported on a large number of IoT platforms based on Intel® x86, ARM*, and MIPS processors. One FPGA developer kit is also supported. Further, MRAA introduces the concept of subplatforms for extending I/Os on existing boards or adding I/O capabilities to systems that have none. These I/O expanders are often offered in the form of an IC or an MCU, and they can be connected to the host device and utilized using the same MRAA APIs. In such cases, the user application runs on the host and communicates with the expander via device drivers or 3rd party communication libraries (e.g., Firmata*).

The current list of supported boards is as follows:

  • X86: Intel® Galileo, Intel® Edison, Intel® Joule™, Intel® NUC DE3815, Intel® NUC5, MinnowBoard MAX*, MinnowBoard Turbot*, Aaeon*, UP*, UP2*, IEI* Tank 870
  • ARM*: Raspberry Pi*, Banana Pi*, Beaglebone* Black, phyBOARD-Wega*, 96Boards* (Bubblegum, DragonBoard, HiKey, Rock, Ultra)
  • MIPS: Linkit* Smart 7688, Onion* Omega2
  • FPGA: Terasic* DE10-Nano
  • Subplatforms: FTDI4222, Arduino 101*, GrovePi+, Generic Firmata* Boards

MRAA also provides the option to define boards or systems using a simple JavaScript* Object Notation (JSON) format. This feature is ideal for devices and systems derived from a reference design provided by Intel, but certainly not limited by it. For instance, developers working on an industrial gateway device, using the standard Linux pseudo devices known to MRAA for the exposed I/Os, can quickly add platform support by providing only the JSON board definition file. This eliminates the task of writing a dedicated board file in C and integrating it with the internals of the MRAA library. Examples of JSON defined platforms are provided for the MinnowBoard Turbot* and the Intel® Aero Compute Board.

NOTE: Unfortunately, the JSON format does not work in situations requiring pin muxing or custom steps to initialize I/Os on the platform. Those scenarios require writing problem-solving at the C level.

The developer community finds it useful to simulate or “virtualize” an IoT board. Currently MRAA implements this feature using a mock platform, allowing developers to write and run applications even on systems that have no exposed I/Os (e.g. a development laptop). This feature promotes early prototyping and development of application logic when hardware is unavailable. Once the intended target becomes available, the application can be migrated to run on the hardware without any changes. The mock platform feature also encourages unit testing among MRAA contributors and is used with the project’s continuous integration (CI) systems. A variation on the mock platform for JavaScript* that is mainly specific to Windows* is offered under the name mraaStub (jsstub).

The MRAA library offers a string initializer feature for the I/O classes. This eliminates the precondition for data type knowledge from higher level frameworks or services that need to initialize and interact with I/Os using the MRAA library. In short, MRAA I/O initializer functions generally use a combination of integers, booleans and strings to specify the required I/O resource. This feature introduces a generic MRAA init_io function which works exclusively on a string input, sending it to an internal parser for decoding and I/O initialization.

IMRAA, a platform configuration service that is part of MRAA, provides platform configuration before user applications initialize the MRAA library. This component has been used mainly for setting up user permissions in order to gain access to I/O resources on Linux systems and to detect and load connected subplatforms when an application is launched. IMRAA could be enhanced, if needed, to act as a daemon for dynamic platform configuration.

At a high level, the MRAA sources are organized as follows:

MRAA is open-source software offered through GitHub*. It can be installed on any Linux* system using the cmake build system, and the project has few dependencies on other system packages, the most notable being SWIG. This source translation framework is necessary if bindings for other supported languages are desired. The supported Operating Systems are:

  • Standard Linux* Distributions: Fedora*, Debian*, Ubuntu*, Ubilinux*, Arch Linux*, OpenSUSE*
  • Embedded Linux* Distributions and Projects: Yocto Project*, OpenEmbedded, 01.org, Wind River Linux*, Wind River Pulsar Linux*, Android Things*
  • Real-time Embedded OS: Zephyr*
  • Windows*: Only using Docker* containers and the mock platform

Contributions are checked through the use of the Travis CI system, unit testing, and static code analysis. A system running Doxygen* on a Jenkins* instance generates documentation. Packaging is done on demand on stable releases only. The community maintains most of the distribution channels for the supported OSes listed above.

Over the course of 2017, the project saw over 30K unique visitors and approximately 15K unique downloads according to GitHub* metrics. Good adoption occurred internally at Intel and externally from key companies such as IBM*, Linaro*/ARM*, Google*, Emutex*, Phytec*, GE*, Technexion*, Qualcomm*, STMicroelectronics*, u-blox*, Honeywell*, Siemens*, Mediatek*, and others. Adoption took place either directly, or through custom-designed Intel® IoT Developer Kit boards requested by some of these partners.

The project is still under active development from by Intel and the developer community. The MRAA project is also tightly integrated with Intel® System Studio, a free product that integrates multiple Intel® tools and libraries with the Eclipse* IDE.

*Other names and brands may be claimed as the property of others.

Why Here?

We believe the MRAA project will achieve synergy with the Eclipse Kura* project. The project may act as a suitable replacement for the rather limited and now inactive jdk.dio framework. While it is true the MRAA Java* bindings are automatically generated with SWIG*, the MRAA project received several updates for type mapping between C++ and Java* to expose a set of Java* APIs with a native look and feel.

There is good synergy with multiple Eclipse* IoT projects such as Eclipse Mosquitto*, Eclipse Paho*, Eclipse Milo*, and other M2M projects. Furthermore, there is a very good integration between MRAA and the Eclipse* IDE already in place in Intel® System Studio. The Eclipse Foundation* may choose to reuse this in existing products.

Nowadays community spans well beyond Intel. The Eclipse Foundation* would encourage vendor neutrality and act as an arbiter in further development of the MRAA project.

Project Scheduling

During the initial phases, the project published stable iterations of the framework to the general public at a fast pace, as new features and bug fixes were constantly becoming available. Currently, the release cadence has settled at two major release per year, which include community contributions and fixes along with planned features and milestones from the project’s roadmap.

Future Work

Library development plans for the upcoming quarters are illustrated in Figure 2.

Figure 2. Future MRAA Development

Near future development focuses on enhancements to the mock platform. The enhancements improve simulation of potential targets, and users receive additional mock I/O classes. These classes include additional configuration options, not only for the I/O APIs themselves but at a mock platform level too (currently this is fixed and offers 1 of each type of I/O only).

Intel plans to continue submitting code for new x86 platform launches and the Intel® IoT Developer Kits. Future releases may involve these features:

  • APIs for the I2S Protocol: I2S is available on many higher end IoT platforms for driving audio devices. This will allow the MRAA library to control microphones and speakers for easier audio and speech-based application development.
  • IMRAA Enhancements: These enhancements appeal to users working at the OEM/ODM and industrial application level. Development here centers on full conversion of the IMRAA to a daemon along with the addition of Socket support.
  • Dynamic FPGA I/O Block Detection: This feature debuted as a proof of concept and will likely be formalized and added to the MRAA library as IoT FPGA developer kit availability increases.
  • C# Language Support: The community added this support through external, hand-written bindings. We are currently investigating if they can be merged into the project or generated through SWIG*.
Initial Contribution

MRAA latest source code base as available at https://github.com/intel-iot-devkit/mraa.

Intel® owns the copyright on approximately 80% of the library’s functional source code. This excludes 3rd party modules, collateral, integrations, tools and other supporting files that are included with the project.

The project includes 3rd party content under the following associated licenses:

  • Boost Software License 1.0
  • BSD 3-clause "New" or "Revised" License
  • MIT License
Source Repository Type

Eclipse IOTA Trinity

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

IOTA is an open-source distributed ledger built with the Internet of Things in mind. It can be leveraged for a number of purposes, including messaging with data integrity and feeless microtransactions.

Trinity was initially developed as a community wallet for the IOTA network, to improve the user experience of sending value tokens between different parties. However the Trinity codebase is currently being modularised to allow different components to be easily reused, in order to build other frontend applications that use the IOTA network.

Scope

Eclipse Trinity is a toolkit to support the cross-platform development of frontend applications on the IOTA network, based on the popular Trinity IOTA wallet.

The IOTA client libraries (eg https://iota.readme.io/docs/overview) and node software (eg https://github.com/iotaledger/iri, https://github.com/iotaledger/entangled) are out of scope for this project.

Description

Eclipse Trinity is a cross-platform toolkit built with React / React Native, and with additional native components where necessary.

  • Core modules support basic functions such as seed storage, address generation and signing.

  • Feature modules may add functionality such as network dashboards, messaging and data management.

  • Design modules add UI customisability.

Why Here?

This project provides a quick entry point for developers exploring the IOTA network, and allows them to rapidly prototype concepts and business models. The governance framework and guidance of the Eclipse Foundation will help to ensure that development meets the requirements of the wider community.

Project Scheduling

The initial contribution is already available and undergoing development. The first builds of the wallet are currently undergoing public beta testing (https://trinity.iota.org/). The roadmap for development is available here: https://trinity.iota.org/roadmap.

The codebase is currently being refactored to separate concerns and provide a more modular structure to reflect its evolution into a frontend toolkit for the IOTA network.

Future Work

The current roadmap is available at https://trinity.iota.org/roadmap. Since open desktop beta, the code has been open-sourced and we are beginning to see more public contributions. There will also be a drive to increase engagement among IOTA’s development community, including improved documentation and design challenges.

A design team will undertake initial PoC development on different use cases to highlight the flexibility and functionality. The toolkit will also be made available during upcoming hackathons to drive uptake.

Initial Contribution

The codebase is separated into three sections: mobile, desktop and shared. The mobile and desktop folders contain platform-specific code covering both functionality and UI. The shared folder contains all transactional logic, shared utils and libraries. Desktop is written in React and built with Electron. Mobile is written primarily in React Native and supports both Android and iOS. Some areas of both the mobile and desktop codebases use native modules, including signature generation, Proof of Work and address generation.

Intellectual Property currently lies with the IOTA Foundation, licensed under Apache 2.0.

Dependencies/licenses report (as of commit 997b0ba)

Source Repository Type

Jakarta NoSQL

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Working Group
Proposal State
Created
Background

The goal of this specification is to ease integration between Java® Applications and NoSQL databases, with a common API to work with different types and vendors of NoSQL databases.

To achieve this, the spec has two layers:

  • Communication API: Exactly what JDBC is to SQL. This API has four specializations, one for each type of database (column, document, key-value and graph). The specializations are independent of each other, optional from the point of the database vendor and have their specific TCKs.

  • Mapping API: What developers should use to integrate into a database. This layer is based on Annotations and CDI and preserves integration with other Jakarta EE technologies like Bean Validation, etc.  



The guiding ideas for the project are:

  • Convention over configuration

  • Support for asynchronous queries

  • Support for asynchronous write operations

  • Easy to implement API, so that NoSQL vendors can comply with it and test by themselves.

  • The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8.

Scope

Jakarta NoSQL defines an API for common behavior to facilitate integration between Java® applications and NoSQL databases.

The Jakarta NoSQL project consists of the following modules:

  • Column Communication API and TCK

  • Document Communication API and TCK

  • Key-Value Communication API and TCK

  • Graph Communication API and TCK

  • Mapping API and TCK

Description

Create the specification in Jakarta EE to help Jakarta EE developers create enterprise-grade applications using Java® and NoSQL technologies. It helps them create scalable applications while maintaining low coupling with the underlying NoSQL technology.

The development of the new API will use Eclipse JNoSQL as a starting point (first compatible implementation and inspiration for the APIs and TCKs):

 

Why Here?

This API has a huge value to the Jakarta EE developers as it will make easier to develop a modern and scalable application using NoSQL technology.

Project Scheduling

The main idea is a community-driven and releases every three months.

 

  • Milestone 1 - Graph Communication API and TCK

  • Milestone 2 - Column Communication API and TCK

  • Milestone 3 - Document Communication API and TCK

  • Milestone 4 - Key-Value Communication API and TCK

  • Milestone 5 - Mapping API and TCK

Project Leads
Mentors
Interested Parties

Community

  • SouJava

  • SouJava Campinas

  • SouJava Rio

  • JavaBahia

  • GuJavaSC

  • London Java Community

 

Individual

  • Gerald Sangudi

  • Prasad Varakur

  • Johan Larson

  • Luca Garulli

  • Werner Keil

  • Christoph Engelbert

  • Daniel Cunha

  • Dor Laor

  • Ondrej Mihályi

  • Jesse Gallagher

Company

  • CouchBase

  • Scylla DB

  • Orientdb

  • Jelastic

  • V2COM

Initial Contribution

The initial goals of the Jakarta NoSQL project are to:

 

  • Receive code donations from https://github.com/eclipse?q=jnosql

  • Setup the governance structure of the project

  • Ensure all donated code is appropriately licensed under the Apache License

  • Define the project modules and structure (API, implementation modules (initially for NoSQL databases, adapter modules, examples)

  • Provide examples demonstrating feature usage

  • Attract contributions from the greater Java community

 

Documentation

Links to some other existing solutions:

 

Databases

Source Repository Type

Eclipse Oscano

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

The scale of modern software systems is growing beyond the capability of individuals and teams to keep track of them. This is caused by new software development and deployment technologies, massive use of open source, devops automation and increasingly powerful hardware. Traditional Software Composition Analysis (SCA) products struggle to keep up with this new scale and its modern methods like continuous integration, continuous package updates and agile releasing. At the same time we have seen a trend of software driven enterprises starting to develop own technology to solve these problems. Instead of relying on vendor solutions the strategy often is to in-source the strategic integration and operation of SCA and partnering and collaboration around open sourcing the technologies. sw360, Open Source Review Toolkit (ORT), Quartermaster and ClearlyDefined are examples of such enterprise-driven projects. They provide valuable partial technologies for continuous dependency, vulnerability and license compliance analysis and automation - yet a complete solution to the problem is still missing. The mission of the Oscano project is to solve the problem of scaling SCA to modern needs with Open Source approach. It aims to integrate the new building blocks into a complete installable SCA solution and act as an industry forum to coordinate coherent further development.

Scope

The Eclipse Oscano project provides a complete software composition analysis solution, focused on compliance and security, that can be installed on cloud, local server, or workstation environment. 

To achieve this, existing OSS components will be reviewed by the project team for possible integration into the Oscano stack. Capabilities not existing as OSS will be built and integrated. Oscano project scope:

  • Creation of an installable open source software distribution providing a solution for large-scale continuous software composition analysis for use cases like open source inventory management, license compliance and vulnerability remediation automation

  • An architecture integrating existing open source SCA technologies and providing interfaces for legacy and vendor SCA systems.

  • An industry coordination forum to ensure sufficient and coherent investment into SCA technology projects and to agree about the architecture

  • Communication and promotion of the Oscano solution

Description

Eclipse Oscano project aims to develop and distribute a complete software composition analysis solution installable on cloud, local server or workstation environment. 

Main use cases of Oscano include Open Source license compliance management, open source inventory management, vulnerability remediation automation and software analysis reporting. 

The solution is designed to meet the challenge of massively increasing scale and continuous nature of build and releasing of modern software systems. It addresses the scaling problem through four principal means: 1. Continuous and fully automated operation cycle from new code commit to analysis, scan and action 2. Maximum engagement of developers in the software analysis and management use cases for direct and early troubleshooting 3. Risk-based smart analysis of compliance and vulnerability issues 4. Maximum re-use of pre-scanned open source software data.

In addition to state-of-the art core SCA functionality the solution provides following features

  • Enterprise integrations for authentication and access control for source access and SCA system operation
  • Interfaces and data conversion to support external software data sources for component meta-data, scan results, compliance and vulnerability data
  • Interface for legacy and vendor software for OSS component inventory management
  • Open Source obligation management solution for automated generation and publishing of obligated materials and managing the workflow.
Why Here?
  • We want to position Oscano as a developer oriented SCA solution. The Eclipse Foundation has been traditionally strong advocate for the developer community through its many popular tools projects. Oscano also puts focus in the developer by integrating its user experience in the existing tools of the developer in form of CLI tools, Eclipse and other IDE plugins, CI script templates and slack plugins. We also expect that Eclipse Foundation can provide Oscano project a neutral institutional setting, more credible IP due diligence, trusted governance framework and an independent distribution source for the project software.  
  • Modern software technologies lead to Big Software stacks on scale not any more workable with manual processing of batch scans. Oscano retains control with continuous scan and fast reaction to high risk issues
    • SECURITY: Automated de-facto code standard leads to secure software and promotes competitive access to vulnerability data

    • SPEED: Continuous scan with developer experience enables immediate action and delegation of fix responsibility to developers

    • COST: Industry-wide re-use of standard component scan data saves cost and time

    • COMPLIANCE: The solution to cover it also in the future

    • LEADERSHIP: Community of enterprise software leaders

Project Scheduling

Current plan is to have a constitutional meeting with contributing parties, in September 2018 - parallel to establishing an Eclipse Working Group. Fourth quarter of 2018, work will start on two fronts: 1. Architecture planning for agreeing the selected already existing open source technologies to use and to plan development of the missing functionality. 2. Distro development starting from the Codescoop initial contribution and aiming to ship the first version (1.0) of a complete solution within 12 months. The first use case to be completed is Open Source license compliance management. The 1.0 version targets to ship it together with basic solution for vulnerability remediation automation. Later releases are planned to ship advanced features of these use cases and support for interfaces for further enterprise integration.

Future Work

After initial function blocks (compliance and security) have been implemented, depending on the contributors votes, additional capabilities may include the following elements:

Project Leads
Mentors
Interested Parties

Disney Company

Siemens AG

Here

ASML

Initial Contribution

The starting point of Oscano software is a cloud distribution of an initial SCA solution for continuous Open Source license compliance analysis and inventory management. It is assembled out of selected major OSS SCA technologies which exist today including Open Source Review Toolkit, SW360, ClearlyDefined API, Fossology and ScanCode. In addition to these core components there is new code to enhance, integrate, configure, build and deploy the distro on public cloud infrastructure with standard docker and kubernetes services.  This solution distribution is provided by Codescoop as the initial contribution on for the Oscano project.

Source Repository Type

Extremo

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Draft
Background

Model-Driven Engineering (MDE) uses models as its main assets in the software development process. The structure of a model is described through a meta-model. Even though modelling and meta-modelling are recurrent activities in MDE and a vast amount of MDE tools exist nowadays, they are tasks typically performed in an unassisted way. Usually, these tools cannot extract useful knowledge available in heterogeneous information sources like XML, RDF, CSV or other models and meta-models.

Scope

We propose an approach to provide modelling and meta-modelling assistance. The approach gathers heterogeneous information sources in various technological spaces, and represents them uniformly in a common data model. This enables their uniform querying, by means of an extensible mechanism, which can make use of services, e.g., for synonym search and word sense analysis. The query results can then be easily incorporated into the (meta-)model being built. The approach has been realized in the Extremo tool, developed as an Eclipse plugin.

Why Here?

Feedback from the community of modellers. New ideas. Give the project a more complete sense and try to push it further.

Initial Contribution

https://github.com/angel539/extremo

Source Repository Type