Project Ocre

Required Information

Responses (Please list N/A if not applicable)

Name of Project

Project Ocre

Project Description (what it does, why it is valuable, origin and history)

Ocre leverages WebAssembly and Zephyr to support OCI-type application containers in a footprint up to 2000x lighter than Linux-based container runtimes such as Docker. Seeded with code from Atym, the mission of the project will be to modernize the embedded space by making it as easy to develop and securely deploy apps for billions of microcontroller-powered edge devices as it is in the cloud.

Statement on alignment with Foundation Mission Statement

Project Ocre is well-aligned with the LF Edge Mission Statement in that it provides an open foundation to extend cloud-native development principles into the Constrained Device Edge. 

High level assessment of project synergy with existing projects under LF Edge, including how the project compliments/overlaps with existing projects, and potential ways to harmonize over time. Responses may be included both here and/or in accompanying documentation. 

Project Ocre is highly complimentary to existing LF Edge infrastructure projects such as Open Horizon and Project EVE in that it extends similar capabilities to devices that can't run Linux.  Ocre can enable containerized apps on microcontroller-powered devices that have as little as 1MB of available memory. 

Link to current Code of Conduct

We will adopt the LFE code of conduct

2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations

Joe Pearson, Erik Nordmark

Project license

Apache 2.0

Source control (GitHub by default)

GitHub

Issue tracker (GitHub by default)

GitHub

External dependencies (including licenses)

Primary dependencies are:

• Zephyr OS (link) - Apache 2.0
• Wasm Micro Runtime (link) - Apache 2.0

Release methodology and mechanics

Regular releases, likely monthly or quarterly.  Releases will use semantic versioning.

Names of initial committers, if different from those submitting proposal

Stephen Berard

Current number of code contributors to proposed project

3

Current number of organizations contributing to proposed project

1

Briefly describe the project's leadership team and decision-making process

We will create a technical leadership committee (target 5 people total).  No more than 2 representatives can come from the same organization/company.

The leadership team will determine the overall decision making process.

List of project's official communication channels (slack, irc, mailing lists)

To be established upon project formation

Link to project's website

To be established upon project formation

Links to social media accounts

To be established upon project formation

Existing financial sponsorship

Yes, via Atym, also an LF Edge member

Infrastructure needs or requests (to include GitHub/Gerrit, CI/CD, Jenkins, Nexus, JIRA, other ...)

GitHub/GitHub Actions, website, email, wiki

Currently Supported Architecture

• Zephyr on Arm Cortex M (M33, M4, M7)
• Linux on x86/x64

Planned Architecture Support

Additions:

• ESP32 (XTensa)
• RISC-V
• MIPS

Project logo in svg format (see https://github.com/lf-edge/lfedge-landscape#logos for guidelines)

Trademark status

Not trademarked

Does the project have a Core Infrastructure Initiative security best practices badge? (See: https://bestpractices.coreinfrastructure.org)

Not at this time.  We are largely compliant with the requirements and will work to obtain this badge in the near team.

In addition to this badge, a defined Secure Development Process is currently being put in place.

Any additional information the TAC and Board should take into consideration when reviewing your proposal?

Project Ocre will provide LF Edge with a great story for the Constrained Device Edge which is currently underserved by the community despite growing in capability and increasingly AI-enabled.

Criteria

Data

2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations

✔

A presentation at an upcoming meeting of the TAC, in accordance with the project proposal requirements

✔

The typical IP Policy for Projects under the LF Edge Foundation is Apache 2.0 for Code Contributions, Developer Certificate of Origin (DCO) for new inbound contributions, and Creative Commons Attribution 4.0 International License for Documentation. Projects under outside licenses may still submit for consideration, subject to review/approval of the TAC and Board.

✔

Upon acceptance, At Large projects must list their status prominently on website/readme

✔

Deployment Type

(Support, Possible, N/A; Add context as needed)

Customer Devices (Edge Nodes)

Support

Customer Premises (DC and Edge Gateways)

Possible - while Ocre is optimized for highly-constrained devices that can’t run Linux (e.g. MCUs), it can also support containers on more capable devices.  

Telco Network Edge (MEC and Far-MEC)

"  "

Telco CO & Regional

“  “

Cloud Edge & CDNs

“  “

Public Cloud

“  “

Private Cloud

“  “

Directly applicable Industry/Verticals use cases

(✔ or X; Add context as needed)

Automotive / Connected Car

✔

Chemicals

✔

Facilities / Building automation

✔

Consumer

✔

Manufacturing

✔

Metal & Mining

✔

Oil & Gas

✔

Pharma

✔

Health Care

✔

Power & Utilities

✔

Pulp & Paper

✔

Telco Operators

✔

Telco/Communications Service Provider (Network Equipment Provider)

✔

Transportation (asset tracking)

✔

Supply Chain

✔

Preventative Maintenance

✔

Water Utilities

✔

Security / Surveillance

✔

Retail / Commerce (physical point of sale with customers)

✔

Other - Please add if not listed above (please notify TAC-subgroup@lists.lfedge.org when you add one)

Use Cases

(✔ or X; Add context as needed)

Gateways (to Cloud, to other placements)

✔ - highly-constrained smart sensors/cameras and some lightweight gateway devices 

NFV Infrastructure

X

Stationary during their entire usable life / Fixed placement edge constellations / Assume you always have connectivity and you don't need to store & forward.

X

Stationary during active periods, but nomadic between activations (e.g., fixed access) / Not always assumed to have connectivity. Don't expect to store & forward.

✔

Mobile within a constrained and well-defined space (e.g., in a factory) / Expect to have intermittent connectivity and store & forward.

✔

Fully mobile (To include: Wearables and Connected Vehicles) / Bursts of connectivity and always store & forward.

✔