AraMDK 0.2

Project Ara
Module Developers Kit (MDK)
Release 0.2 (alpha)

January 8, 2015
Copyright 2015 Google Inc. All rights reserved. Your use of this Ara Module Developers Kit (MDK) is expressly
subject to the terms of the MDK License Agreement found at http://projectara.com/mdk-license.txt.
MDK Release 0.2 (alpha)
January 8, 2015
Page 1 of 107
Welcome. What now?

Project Ara is a platform for creating modular smartphones. Users will be able to start with an
Endoskeleton, the structural frame and network backbone of the device, and populate it with
modules, the building blocks that make up the vast majority of the phones functionality and
features. Since modules are interchangeable, a user has the freedom to design exactly the
phone they want and continue to customize the phone over time by replacing modules. Aras
success is predicated on a rich, vibrant, and diverse ecosystem of modules from a myriad of
developers. Users would be able to select modules from an online marketplace using a
con;gurator that facilitates user choice and curates the con;guration process to ensure that
the selection of modules provides the expected system-level functionality.
This document, which serves as the narrative and core of the Module Developers Kit (MDK),
discusses how to develop modules compatible with the Ara platform. Note that while this
document extensively describes the Endoskeleton, or Endo, it does so exclusively for the
bene;t of module developers to ensure compatibility between modules and the Endo. The Ara
platform does not presently support third-party Endo developers.
Chapter 1 provides a brief description of the licensing landscape that governs the Ara
ecosystem. Chapter 2 talks about the industrial design of the Ara platform including the
physical layout of the frame, the Endoskeleton or Endo, and how modules ;t within it.
Chapter 3 talks about the mechanical and electrical assemblies and interfaces of Ara modules.
Chapter 3 also provides reference design templates for each type of module. Chapters 4 and 5
talk about power and networking between the Endo and modules. Chapter 6 discusses the Ara
software platform and how it interacts with various types of hardware devices. Chapter 7 talks
about system-level functions, which require interactions between modules and the Endo.
Chapter 8 discusses compliance criteria to ensure module compatibility with the MDK, such as
environmental speci;cations, thermal loads, electromagnetic compatibility, and corresponding
test protocols. Chapter 9 describe what is provisionally known as the Ara Module Marketplace,
and the process for submitting and selling modules through the Ara Module Marketplace.
Finally, Chapter 10 provides some guidelines for regulatory compliance and carrier certi;cation.
This document provides speci;cation requirements needed to ensure compatibility with the Ara
platform. Heading titles throughout the document mark sections that contain speci;cation
language.
This document also provides reference implementation material to demonstrate exemplars that
comply with the Ara speci;cations. Reference implementation material is in blue text
January 8, 2015
Page 2 of 107
throughout the document. Heading titles also mark sections that contain reference
implementation material.
Known vendors are provided for various components which are deemed scarce. These
sections are highlighted in purple. Google in no way endorses these vendors.
All MDK releases prior to release 1.0 are considered prototype releases. These are validated
using prototype hardware and software implementations that frequently fall short of the
objective speci;cation. Consequently, some elements of the prototype speci;cations and
reference implementations will diGer from the objective system. Blue boxes like this one
denote distinctions between the current prototype platform and the objective one throughout
the document.
January 8, 2015
Page 3 of 107
Contributors
The following individuals made signi;cant contributions to the development of the MDK.
Google
Elwin Ong (principal author), Paul Eremenko, David Fishman, Jason Chua,
Mark Rich, Greg Kielian, Adam Holman, Roshni Srinivasan, Anil
Rachakonda, Srinivas Nori
NK Labs
Seth Newburg, Ara Knaian, Marisa Bober, Dave McCoy, Charles Mycroft
Hannum, Boyan Kurtovich, Shahriar Khushrushahi, Nan-Wei Gong, Chris
Wardman, Nate MacFadden
LeafLabs
Marti Bolivar, Perry Hung, Andrew Meyer
New Deal Design
Dan Clifton, Gadi Amit, Inbal Etgar, Susan McKinney
Metamorph Software
Sandeep Neema, Ted Bapty
X5 Systems
Derek Linden
Toshiba
Yukio Watanabe, Toshihide Fujiyoshi, Takuma Aoyama, Kaoru Kamata,

Takeshi Oto, Yasuo Ohara, Eugene Chang, Joachim Hausmann
Mixel
Ashraf Takla
Quanta
Dexter Yeh, Venney Lin, Hans Chang, Barry Tsao, Suya Hou, Rigii Ni,
Sam Kuo, Alens Lin, Sunny Tsai
Opersys
Karim Yaghmour
Linux Solutions
Greg Kroah-Hartman
Linaro
George Grey, Rob Herring, John Stultz, Khasim Mohammed, Vishal Bhoj,
Alex Elder, Glen Valante, Matt Porter, Satish Patel, Viresh Kumar, Bin Chen
BayLibre
Fabien Parent, Alexandre Bailon, Benoit Cousson
NewOldBits
Jean Pihet
Oxford Systems
Olin Sibert
Foxconn Interconnect
Technology (FIT)
Jason Chou, Shan-Ting Hsu, Sutchaya Lertburapa, Pitt Lin, Mickey Ge
IDT Systems
Peter Woodd, Kevin Baumber, Sangsoo Yim
January 8, 2015
Page 4 of 107
Support
The Project Ara team cannot, as a general matter, provide individualized support to module
developers. If you have a comment on the MDK, have found a bug, or would like to provide
feedback, you can reach the Project Ara team at ara-dev@google.com.
Developer documentation will be maintained at http://projectara.com/mdk, including a set of
Frequently Asked Questions (FAQs) which will be updated periodically.
Developers are also encouraged to join the Ara Module Developers Google Group at
http://groups.google.com/forum/#!forum/ara-module-developers, which serves as a forum and
mailing list. If your question is not addressed in the latest documentation or FAQ, it may well
have been answered in the Google Group. If not, ask away!
Limited quantities of prototype hardware, including dev boards are available by submitting a
request at http://www.projectara.com/dev-boards/.
January 8, 2015
Page 5 of 107
Revision History
Release 0.10 (alpha) - April 9, 2014 - Initial public release
Release 0.11 (alpha) - May 28, 2014
Fixed typos in document and reference materials.
Updated power speci;cations; added ;gures to illustrate multiple battery con;gurations
and battery charging events.
Fixed prototype ambient temperature and humidity speci;cations.
Added Prototype Endo Medium Frame CAD ;les to reference materials.
Added Prototype 1x2 and 2x2 Module Shell CAD ;les to reference materials.
Added Prototype EPM build instructions to reference materials.
Added contactless media converter prototype reference implementation.
Separated known vendor sections from reference implementations.
Release 0.2 (alpha) - January 8, 2015
Updated all prototype implementations sections to reQect Spiral 2 design.
Consolidated CMF speci;cations and reference implementation to Section 2.
Updated Layer 1 contactless media converter (CMC) from capacitive to inductive and
included draft CMC speci;cation as a separate document in reference materials.
Updated FPGA UniPro implementation with Toshiba HS and GP Bridge ASICs.
Updated Layer 5+ network, introduced Greybus Application Protocol, and included
Greybus speci;cation in a separate document in the reference materials.
Updated objective software architecture and Spiral 2 prototype reference
implementation.
Updated environmental section to include all MDK compliance speci;cations.
Added initial description of Ara Module Marketplace requirements.
January 8, 2015
Page 6 of 107
Table of Contents
1. Licensing
1.1.
The Ara MDK License
1.2.
External Licenses
1.2.1.
MIPI
1.2.2.
Android
1.2.3.
Linux
1.2.4.
Other IP
1.2.5.
Prototype Platform External Licenses
1.2.5.1.
I2C
1.2.5.2.
I2S
1.2.5.3.
SDIO
1.2.5.4.
High-Speed Inter-Chip USB
1.2.5.5.
DSI, CSI-2
2. Industrial Design
2.1.
De;nitions
2.2.
Parceling Schemes
2.2.1.
Rear Parceling Scheme
2.2.2.
Front Parceling Scheme
2.3.
Design Language
2.3.1.
Geometric Design Language - Speci;cation
2.3.2.
Geometric Design Language - Reference Implementation
2.3.3.
Color Material Finish - Speci;cation
2.3.4.
Color Material Finish - Prototype Reference Implementation
3. Mechanical and Layout
3.1.
Module Geometry and Assemblies
3.1.1.
Rear Module Sub-Assemblies
3.1.1.1.
Rear Module Sub-Assemblies - Speci;cation
3.1.1.2.
Rear Module Sub-assemblies - Prototype Reference
Implementation
3.1.1.2.1. Rear Module Templates - Prototype Reference Implementation
3.1.1.2.2. 1x2 Camera Module - Prototype Reference Implementation
3.1.1.2.3. 1x2 Speaker Module - Prototype Reference Implementation
3.1.1.2.4. 2x2 Marvell AP Module - Prototype Reference Implementation
3.1.1.2.5. 2x2 NVidia AP Module - Prototype Reference Implementation
3.1.1.3.
Hiperco-50 - Known Vendors
3.1.2.
Front Module Sub-assemblies
3.1.2.1.
Front Module Sub-assemblies - Speci;cation
January 8, 2015
Page 7 of 107
3.1.2.2.
Front Module Sub-assemblies - Prototype Reference
Implementation
3.1.2.2.1. Receiver Module - Prototype Reference Implementation
3.1.2.2.2. Display Module - Prototype Reference Implementation
3.1.3.
Module Label
3.1.3.1.
Module Label - Speci;cation
3.1.3.2.
Module Label - Prototype Reference Implementation
3.1.4.
Envelope Violation Limitations
3.1.4.1.
Envelope Violation - Speci;cation
3.1.4.2.
Envelope Violation - Reference Implementation
3.1.4.3.
Envelope Violation - Prototype Reference Implementation
3.1.4.4.
1x2 Pollution Sensor Module - Prototype Reference
Implementation
3.2.
Connectors
3.2.1.
Interface Block
3.2.1.1.
Interface Block - Speci;cation
3.2.1.2.
Interface Block - Prototype Reference Implementation
3.2.1.3.
Front Module Attachment - Speci;cation
3.2.1.4.
Front Module Attachment - Prototype Reference Implementation
3.3.
Antennas
3.3.1.
Antenna in Module - Speci;cation
3.3.2.
1x2 WiFi/BT Module with Antenna - Prototype Reference Implementation
3.3.3.
Antenna Interface - Speci;cation
3.3.4.
Antenna Interface - Prototype Reference Implementation
3.3.4.1.
1x2 3G Cellular Module - Prototype Reference Implementation
3.3.4.2.
1x1 Antenna Module - Prototype Reference Implementation
4. Power
4.1.
Power Consumer Module - Speci;cation
4.2.
Power Consumer Module - Prototype Reference Implementation
4.3.
Charger Module - Speci;cation
4.4.
USB Charger Module - Prototype Reference Implementation
4.5.
Power Storage Module - Speci;cation
4.6.
Battery Modules - Prototype Reference Implementation
5. Network Stack
5.1.
Module Communication Physical View
5.2.
Network Stack
5.2.1.
Layer 1
5.2.1.1.
Layer 1 Contactless Media Converter - Speci;cation
5.2.1.2.
Layer 1 Contactless Media Converter - Reference Implementation
5.2.1.3.
Layer 1 Contactless Media Converter - Prototype Reference
Implementation
January 8, 2015
Page 8 of 107
5.2.1.4.
Layer 1 MIPI M-PHY - Speci;cation
5.2.1.5.
Layer 1 MIPI M-PHY - Reference Implementation
5.2.1.6.
Layer 1 MIPI M-PHY - Known Vendor(s)
5.2.1.7.
Layer 1 M-PHY - Prototype Reference Implementation
5.2.1.8.
Layer 1 D-PHY - Prototype Speci;cation
5.2.1.9.
Layer 1 D-PHY - Prototype Reference Implementation
5.2.2.
Layers 1.5-4
5.2.2.1.
Layers 1.5-4 MIPI UniPro - Speci;cation
5.2.2.2.
Layers 1.5-4 UniPro - Reference Implementation
5.2.2.3.
Layers 1.5-4 UniPro - Known Vendor(s)
5.2.2.4.
Layers 1.5-4 CSI-2 - Prototype Speci;cation
5.2.2.5.
Layers 1.5-4 CSI-2 - Prototype Reference Implementation
5.2.2.6.
Layers 1.5-4 DSI - Prototype Speci;cation
5.2.2.7.
Layers 1.5-4 DSI - Prototype Reference Implementation
5.2.2.8.
Layers 1.5-4 Bridged Interfaces
5.2.2.8.1. HSIC Bridge - Prototype Speci;cation
5.2.2.8.2. HSIC Bridge - Prototype Reference Implementation
5.2.2.8.3. I2C Bridge - Prototype Speci;cation
5.2.2.8.4. I2C Bridge - Prototype Reference Implementation
5.2.2.8.5. I2S Bridge - Prototype Speci;cation
5.2.2.8.6. I2S Bridge - Prototype Reference Implementation
5.2.2.8.7. SDIO Bridge - Prototype Speci;cation
5.2.2.8.8. SDIO Bridge - Prototype Reference Implementation
5.2.2.8.9. GPIO Bridge - Prototype Speci;cation
5.2.2.8.10. GPIO Bridge - Prototype Reference Implementation
5.2.2.8.11. UART Bridge - Prototype Speci;cation
5.2.2.8.12. UART Bridge - Prototype Reference Implementation
5.2.2.8.13. PWM Bridge - Prototype Speci;cation
5.2.2.8.14. PWM Bridge - Prototype Reference Implementation
5.2.3.
Layers 5+
5.2.3.1.
Layers 5+ - Greybus Speci;cation
5.2.3.2.
Layers 5+ - Greybus Prototype Reference Implementation
5.2.4.
Network Stack Hardware - Known Vendor(s)
5.2.5.
Network Stack Prototype Hardware - Known Vendor(s)
6. Software Stack
6.1.
Kernel
6.1.1.
Kernel - Speci;cation
6.1.2.
Kernel - Reference Implementation
6.1.3.
Kernel - Prototype Reference Implementation
6.2.
Android
6.2.1.
Android HALs - Prototype Reference Implementation
January 8, 2015
Page 9 of 107
6.2.2.
Android Application - Speci;cation
6.2.3.
Android Application - Reference Implementation
6.2.4.
Android Application - Prototype Reference Implementation
6.3.
Prototype Development Use cases
6.3.1.
CSI-2/DSI Devices
6.3.2.
I2C, UART, GPIO, PWM Devices
6.3.3.
USB, SDIO, I2S Devices
7. System-Level Functions
7.1.
Module Wake/Detect
7.1.1.
Module Wake/Detect Electrical - Speci;cation
7.1.2.
Module Wake/Detect Electrical - Prototype Reference Implementation
7.2.
Module Initialization/Hotplug Event
7.2.1.
Module Information - Speci;cation
7.2.2.
Module Information - Prototype Reference Implementation
7.3.
Active Thermal Management
7.4.
Power Management
8. Module Compliance
8.1.
Environmental Compliance
8.1.1.
Thermal Loads
8.1.1.1.
Thermal Loads - Speci;cation
8.1.1.2.
Thermal Loads - Prototype Speci;cation
8.1.1.3.
Thermal Loads - Prototype Reference Implementation
8.1.2.
Ambient Temperature and Humidity
8.1.2.1.
Ambient Temperature and Humidity - Speci;cation
8.1.2.2.
Ambient Temperature and Humidity - Prototype Reference
Implementation
8.1.3.
Electrostatic Discharge (ESD)
8.1.3.1.
ESD - Speci;cation
8.1.3.2.
ESD - Prototype Reference Implementation
8.1.4.
Shock
8.1.4.1.
Shock - Speci;cation
8.1.4.2.
Shock - Prototype Reference Implementation
8.1.5.
Vibration
8.1.5.1.
Vibration - Speci;cation
8.1.5.2.
Vibration - Prototype Reference Implementation
8.2.
Mechanical Compliance
8.2.1.
Mechanical Fit
8.2.1.1.
Mechanical Fit - Speci;cations
8.2.1.2.
Mechanical Fit - Prototype Reference Implementation
8.2.2.
EPM Hold
8.2.2.1.
EPM Hold - Speci;cations
January 8, 2015
Page 10 of 107
8.2.2.2.
EPM Hold - Prototype Speci;cations
8.2.2.3.
EPM Hold - Prototype Reference Implementation
8.3.
Power Compliance
8.3.1.
Voltage Sweep
8.3.1.1.
Voltage Sweep - Speci;cations
8.3.1.2.
Power Sweep - Prototype Reference Implementation
8.3.2.
Power Input/Output Noise
8.3.2.1.
Power Input/Output Noise - Speci;cations
8.3.2.2.
Power Input/Output Noise - Prototype Reference Implementation
8.3.3.
Power Draw and Discharge
8.3.3.1.
Power Draw and Discharge - Speci;cations
8.3.3.2.
Power Draw - Prototype Reference Implementation
8.3.4.
Power Storage Capacity
8.3.4.1.
Power Capacity - Speci;cations
8.3.4.2.
Power Storage Capacity - Prototype Reference Implementation
8.4.
Network Compliance
8.4.1.
M-PHY Compliance
8.4.1.1.
M-PHY Compliance - Speci;cations
8.4.1.2.
M-PHY Compliance - Prototype Reference Implementation
8.4.2.
UniPro Compliance
8.4.2.1.
UniPro Compliance - Speci;cations
8.4.2.2.
UniPro Compliance - Prototype Reference Implementation
8.4.3.
Layer 5+ Greybus Compliance
8.4.3.1.
Layer 5+ Greybus Compliance - Speci;cations
8.4.3.2.
Layer 5+ Greybus Compliance - Prototype Reference
Implementation
8.5.
Software Compliance
8.5.1.
Kernel Compliance
8.5.1.1.
Kernel Compliance - Speci;cations
8.5.1.2.
Kernel Compliance - Prototype Reference Implementation
8.5.2.
Android Compliance
8.5.2.1.
Android Compliance - Speci;cations
8.5.2.2.
Android Compliance - Prototype Reference Implementation
8.6.
System-Level Functions Compliance
8.6.1.
Wake/Detect Compliance
8.6.1.1.
Wake/Detect Compliance - Speci;cations
8.6.1.2.
Wake/Detect Compliance - Prototype Reference Implementation
8.6.2.
Hotplug Compliance
8.6.2.1.
Hotplug Compliance - Speci;cations
8.6.2.2.
Hotplug Compliance - Prototype Reference Implementation
9. Ara Module Marketplace
January 8, 2015
Page 11 of 107
9.1.
Ara Developer Console
9.1.1.
Signup and Module Submission
9.1.2.
Module Merchandising Data
9.1.3.
Sales Metrics and Performance Tracking
9.1.4.
Payments Disbursement
9.2.
Logistics and Distribution
9.3.
Module Identi;ers
10. Regulatory Compliance and Carrier Certi;cation
10.1. US Regulatory Compliance and Carrier Certi;cation
10.1.1.
US RF Regulatory Authorization
10.1.1.1.
FCC Equipment Authorization - Speci;cation
10.1.1.2.
FCC Equipment Authorization - Reference Implementation
10.1.1.2.1. FCC Equipment Authorization - Reference Implementation for
Hobbyist/Maker
10.1.1.2.2. FCC Equipment Authorization - Prototype/Experimental License
10.1.2.
US Medical Device Regulation
10.1.2.1.
FDA Regulation - Speci;cation
10.1.2.2.
Pulse Oximeter Module - FDA Regulation - Reference
Implementation
10.1.2.3.
FDA Regulation - Prototype Reference Implementation
10.1.3.
Carrier Terminal Acceptance
10.2. International Certi;cation
January 8, 2015
Page 12 of 107
List of Figures
Figure 2.1 - Ara Phone Built Based on Medium Endo
Figure 2.2 - Ara Endo (Medium Variant)
Figure 2.3 - Ara Rear Parceling Scheme for Jumbo, Medium, and Mini Con;gurations
Figure 2.4 - Valid Medium Endo Con;gurations (Rear)
Figure 2.5 - Rear Modules
Figure 2.6 - Valid Endo Con;gurations (Front)
Figure 3.1 - Rear Module Sub-assemblies
Figure 3.2 - Prototype Module Base
Figure 3.3 - Prototype 1x2 PCB
Figure 3.4 - Prototype Shield and Clips
Figure 3.5 - Module Label Speci;cations
Figure 3.6 - Pulse Oximeter Module with Y-Dimension Exceedance
Figure 3.7 - Modules with Z-Dimension Exceedances
Figure 3.8 - Custom Module Shell for Prototype Camera Module
Figure 3.9 - Interface Block with Inductive Pads
Figure 3.10 - Prototype Interface Block Pinout
Figure 3.11 - Closeup View of Front-Module Attachment Assembly
Figure 3.12 - Example of Antenna Pattern on Module Shell
Figure 3.13 - RF Bus in Endo Enables Routing Between Modules on Top and Bottom Halves
Figure 4.1 - Power Architecture
Figure 4.2 - Power Bus Voltage With Multiple Battery Modules
Figure 4.3 - Battery Charging
Figure 5.1 - Module to Module Communication (with Native UniPro and Bridge ASICs)
Figure 5.2 - Prototype Module to Module Communication
Figure 5.3 - Inductive Communication Between PCBs
Figure 5.4 - Contactless Media Converter
Figure 5.5 - Interface Block Unique IDs
Figure 5.6 - Network Stack over Software and Hardware
Figure 5.7 - Prototype Network Stack over Software and Hardware
Figure 6.1 - Software Stack
Figure 6.2 - Prototype Software Stack
Figure 6.3 - Kernel Subsystem Interfaces
Figure 6.4 - Prototype Greybus Subsystem Reference Implementation
Figure 6.5 - Ara Android Stack
Figure 7.1 - Prototype Reference Implementation of Wake/Detect Circuit
Figure 7.2 - Module Initialization Process Sequence Diagram
January 8, 2015
Page 13 of 107
List of Tables
Table 2.1 - Ara De;nitions
Table 2.2 - Design Language Geometric Guidelines
Table 2.3 - Design Language CMF Speci;cations
Table 3.1 - Rear Module Maximum PCB Dimensions
Table 3.2 - Prototype Rear Module Z Dimension Stackup
Table 3.3 - Prototype Rear Module Templates
Table 3.4 - 1x2 Prototype Camera Module Reference Implementation
Table 3.5 - 1x2 Prototype Speaker Module Reference Implementation
Table 3.6 - 2x2 Prototype Marvell AP Module Reference Implementation
Table 3.7 - 2x2 Prototype NVidia AP Module Reference Implementation
Table 3.8 - Hiperco-50 Known Vendors
Table 3.9 - Front Module Outer Dimensions and PCB Dimensions
Table 3.10 - Prototype Front Module Z Dimension Stackup
Table 3.11 - Prototype Receiver Module Reference Implementation
Table 3.12 - Prototype Display Module Reference Implementation
Table 3.13 - Envelope Violation Limits
Table 3.14 - Prototype Pollution Sensor Module Reference Implementation
Table 3.15 - Prototype Interface Block Pinout Descriptions
Table 3.16 - 1x2 Prototype WiFi/BT Module Reference Implementation
Table 3.17 - 1x2 Prototype 3G Cellular Module Reference Implementation
Table 3.18 - 1x1 Prototype Antenna Module Reference Implementation
Table 4.1 - 1x2 Prototype USB Charger Module Reference Implementation
Table 4.2 - 2x2 Prototype Battery Module Reference Implementations
Table 5.1 - Ara Network Stack
Table 5.2 - Prototype Ara Network Stack
Table 5.3 - MIPI M-PHY Known Vendors
Table 5.4 - MIPI UniPro Known Vendors
Table 5.5 - Toshiba UniPro Bridge ASIC Speci;cations
Table 9.1 - Tech Data Package Items (TBD)
Table 9.2 - Module Support Package Items (TBD)
Table 9.3 - Module Merchandising Data
Table 9.4 - Module Identi;cation Numbers
January 8, 2015
Page 14 of 107
Acronyms
These are some of the acronyms that frequently occur in this document.
ABI
Application Binary Interface
AP
Application Processor
API
Application Programming Interface
ASIC
Application Speci;c Integrated Circuit
BOM
Bill of Materials
CAD
Computer-Aided Design
CMC
Contactless Media Converter
CMF
Color, Material, Finish
CSI
Camera Serial Interface
DSI
Display Serial Interface
EDA
Electronic Design Automation
EPM
Electro-Permanent Magnets
FPGA
Field Programmable Gate Array
GP Bridge
General Purpose Bridge ASIC
GPIO
General Purpose Input Output
GPS
Global Positioning System
HAL
Hardware Abstraction Libraries
HS Bridge
High-Speed Bridge ASIC
HSIC
High-Speed Inter Chip (USB)
I2C
Inter Integrated Circuit
I2S
Integrated Interchip Sound
IMS
Internal Master Secret
IP
Intellectual Property (generally not Internet Protocol)
January 8, 2015
Page 15 of 107
LTE
Long-Term Evolution
LVDS
Low-Voltage DiGerential Signaling
MDK
Module Developers Kit
MIPI
Refers to mobile industry standards alliance
M-PHY
MIPI Physical Layer Speci;cation
MSP
Module Support Package
OS
Operating System
OSI
Open Systems Interconnection
PCB
Printed Circuit Board
PWM
Pulse Width Modulation
RC
Resistor-Capacitor (i.e., RC circuit)
RHC
Remote Host Controller
RTOS
Real-time Operating System
SDIO
Secure Digital Input Output
SLVS
Scalable Low-Voltage Signaling
STEP
Standard for the Exchange of Product Model data
TDP
Tech Data Package
UFS
Universal Flash Storage
UniPro
MIPI Uni;ed Protocol
USB
Universal Serial Bus
January 8, 2015
Page 16 of 107
1.
Licensing
This section discusses certain intellectual property licensing considerations for Ara module
developers. This section is a summary and not a replacement or substitute for the MDK
License Agreement which governs licensing of the MDK. This summary should not be
construed as legal advice.
1.1.
The Ara MDK License
The MDK is licensed in accordance with the MDK License Agreement (Jan 7, 2015). The
agreement is meant to provide a permissive license to module developers, while ensuring the
vibrancy and integrity of the Ara developer ecosystem in the long run. One of the more notable
features of the MDK license is that it provides developers, in addition to a development license,
an upfront grant of commercialization rights, conditioned only on developers playing nice
with the rest of the Ara ecosystem. Also noteworthy is that the MDK license does not alter any
of the standard open source software licenses associated with Android or any Ara-speci;c
drivers, apps, etc. that are distributed as part of the MDK. The MDK license does not allow-nor does the MDK speci;cation facilitate--the development or commercialization of Ara
Endoskeletons by third-party developers.
1.2.
External Licenses
Project Ara strives to embrace industry standards where possible. Consequently, the MDK
references numerous external standards and speci;cations. These are available in accordance
with their speci;c license agreements and are neither owned by Google nor part of the MDK.
Below is a brief summary of these external licenses.
1.2.1. MIPI
The MIPI Alliance is an open membership industry consortium that develops interface
speci;cations for mobile devices. Ara modules implement several MIPI speci;cations. At
minimum, modules communicate with the Endo and with other modules using the MIPI M-PHY
and UniPro speci;cations. Depending on the application, some modules may implement
additional MIPI speci;cations such as CSI and DSI. In order to get a hold of the detailed MIPI
speci;cation, you need to join the MIPI Alliance. This gives you a royalty-free license to
implement your own version of the MIPI interfaces. Alternatively, developers may procure from
third-party vendors IP blocks (for use in FPGAs or in creating ASICs) or complete bridge chips
implementing the MIPI standard interfaces.
1.2.2. Android
The software stack for the Ara platform is built on the open source Android OS. The majority of
Android software including Android software modi;ed/developed for Ara is provided under the
Apache 2.0 license. Except for the preservation of the copyright notice and disclaimer, this
license allows the user of the software the freedom to use the software for any purpose, to
January 8, 2015
Page 17 of 107
distribute it, to modify it, and to distribute modi;ed versions of the software, under the terms of
the license, without concern for royalties.
1.2.3. Linux
The Android OS is built on the Linux kernel. The Linux kernel and its derived works, including
kernel drivers, are distributed under the terms of the GNU General Public License, version 2.
1.2.4. Other IP
To the extent that you utilize intellectual property from other sources, you are responsible for
obtaining approved licenses to implement and market their modules.
1.2.5. Prototype Platform External Licenses

1.2.5.1.
I2C
The current prototype platform uses the I2C bus standard implemented as a bridged
protocol between modules and the Application Processor. The I2C bus standard is
copyrighted by NXP Semiconductors, and is provided free of charge on their website.
1.2.5.2.
I2S
The current prototype platform uses the I2S bus standard implemented as a bridged protocol
between modules and the Application Processor. The I2S standard is available online here
and here.
1.2.5.3.
SDIO
The current prototype platform uses the SDIO bus standard implemented as a bridged
protocol between modules and the Application Processor. The standard is copyrighted by
the SD Card Association and provided free on their website.
1.2.5.4.
High-Speed Inter-Chip USB
The current prototype platform uses HSIC USB in several modules. The standard is
copyrighted but provided free of charge on the USB Implementers Forum website.
1.2.5.5.
DSI, CSI-2
In the current prototype platform, the DSI and CSI-2 standards are implemented in the
prototype Display Module, Camera Module, and the Application Processor Modules. These
standards are copyrighted by the MIPI Alliance and require an approved license to implement
or provided through a third-party with an approved license.
January 8, 2015
Page 18 of 107
2.
Industrial Design
2.1.
De$nitions
The Ara architecture requires the introduction of several new concepts to the traditional mobile
device lexicon. These terms are de;ned in Table 2.1 below and illustrated in Figures 2.1 and
2.2.
Table 2.1 - Ara De$nitions
Term
De$nition
Module
Modules are the building blocks of an Ara phone. They are the hardware
analogue to software apps. These are physical components that
implement various phone functions. There are currently two major
classes of modules: Front modules, which make up the front of the
phone and generally provide user interaction or interface the display,
receiver, microphone, etc., and rear modules, which provide the bulk of
the phones back-end (non-user facing) functionality. Front modules
reach across the entire width of a particular Endoskeleton frame, while
rear modules come in three standard sizes (1x1, 1x2, and 2x2) and can
;t into multiple frame sizes. (See Figure 2.3)
Endoskeleton (Endo)
The Ara Endoskeleton (or Endo) is the frame and backplane of the
device, determining the size and layout of the phone. Ara modules slide
in and attach to the Endos slots, which has a backplane to electrically
and logically connect modules together. There are currently three Endo
size variants: Mini, Medium, and Jumbo, with varying rib con;gurations
for each. Note that the MDK only details the speci;cation of the Endo to
the extent that it is necessary for module developers to develop
modules. In the interest of maintaining the integrity of the Ara platform
speci;cation, third-party Endo development is not permitted.
Spine (Endo Spine)
A singular vertical feature that bisects the rear of the Endo and forms
part of the module slots. (See Figures 2.1 and 2.2)
Rib (Endo Rib)
Horizontal features located either in the front or the rear of the Endo and
forms part of the module slots. Note that the rib con;guration shown in
Figures 2.1 and 2.2 is an instance of a rib arrangement and not the only
possible arrangement. (See Figure 2.4)
Top
The orientation of the primary display module determines the top of

the phone. The top of the phone is de;ned as the direction in which the
volume buttons aTxed to the display module are biased. (See Figure
2.1, volume buttons are required on all primary display modules)
Phone Coordinate Axes

(X, Y, Z)
The Ara platform uses the Android de;ned coordinate system. The
Side-to-Side direction de;nes the X axis. The Top-Bottom direction
de;nes the Y axis. The thickness direction de;nes the Z axis. (See
Figure 2.1)
January 8, 2015
Page 19 of 107
Interface Block
The interface block is the area on the Endo and the modules where the
electrical power pins and contactless data pads are located.
Electro-Permanent
Magnets (EPM)
The Endo contains electro-permanent magnets (EPMs) to attach and

secure each module. The EPMs are activated upon module insertion
and deactivated by the user with an Android application.
Module Shell
The module shell is a user-replaceable cover for Ara modules that can
be aesthetically customized as part of the Ara ful;llment process. With a
few exceptions as noted in the MDK, Ara modules should nominally
support user serviceable module shells.
Figure 2.1 - Ara Phone Built Based on Medium Endo
January 8, 2015
Page 20 of 107
Figure 2.2 - Ara Endo (Medium Variant)
2.2.
Parceling Schemes
Parceling schemes are rules that determine how and where modules can be placed in the Endo
frame. The front parceling scheme only has a few possible layouts, while the rear parceling
scheme can have many diGerent con;gurations depending on the location of the ribs.
2.2.1. Rear Parceling Scheme

The rear of the Endo is parceled into 1x1 unit squares. Each 1x1 square is approximately 22
mm. 1x2 and 2x2 modules are approximately 22x44mm and 44x44mm respectively. Note that
the thickness of the missing rib must be accounted for to conform to the overall grid scheme.
Refer to the computer-aided design (CAD) models and drawings for exact dimensions. All three
Endo sizes use the same rear parceling scheme so modules can be shared between Endo size
variants.
January 8, 2015
Page 21 of 107
Figure 2.3 - Ara Rear Parceling Scheme for Jumbo, Medium, and Mini Con$gurations
As shown in Figure 2.3, a Medium Endo variant is composed of a 3x6 parceled grid while the
Mini and Jumbo variants are 2x5 and 4x7 respectively. Furthermore, the following design rules
govern the placement of the spine and ribs on the rear of the Endo:
Endos must have exactly one vertical spine.

The Medium variant spine must be at a 1:2 horizontal oGset from the centerline of the device as
viewed from the rear.
The Mini and Jumbo variant spine must be in the middle.
For the horizontal ribs, there must be at least 1 rib per 2 units (since modules cannot be larger
than 2x2).
Only a single cross is allowed in an Endo (that is, only one rib can go straight across the spine
on both sides).
The application of these design rules results in a discrete set of possible Endo con;gurations
for each size variant. Figure 2.4 shows the valid set of rear Endo con;gurations for the Medium
January 8, 2015
Page 22 of 107
variant. While Google may or may not make every possible Endo variant available, developers
should be mindful that modules should support every variant.
Figure 2.4 - Valid Medium Endo Con$gurations (Rear)
The Ara parceling scheme and Endo design rules enable the three rear modules to be used
across multiple Endo sizes. A 1x2 module can be used on all three Endo size variants, while a
2x2 module can be used on the Jumbo and Medium Endo variants, and a 1x1 module can be
used on the Medium and Mini Endo variants. Note also that a 1x2 module can be inserted into
an Endo either in the vertical or horizontal orientation.
January 8, 2015
Page 23 of 107
Figure 2.5 shows the front and rear views of rear modules with standard module shells
installed. Note that all rear modules should nominally support user-replaceable module shells.
Module shells attach to rear modules via mechanical snap-;t features built into the module
base and shell itself.
Replaceable module shells are a unique feature of the Ara architecture. They allow users to
aesthetically customize their Ara phone by leveraging injection-molded polycarbonate plastic
and dye sublimation process to create full-color and high-resolution shell designs, and if
desired, to replace module shells any time thereafter.
Figure 2.5 also shows the locations of the interface blocks for each module. Note that 2x2
modules may support an optional second interfaces block for increased power and data
utilization.
Figure 2.5 - Rear Modules
2.2.2. Front Parceling Scheme

The following design rules govern the front parceling scheme:
January 8, 2015
Page 24 of 107
Vertical spines are not allowed - all modules must ;ll the complete horizontal width
A maximum of 2 ribs are allowed
Only a single rib is allowed in each of the upper or lower halves
The parceling scheme for the front Endo results in modules that are proportionally sized for
each Endo size variant. Figure 2.6 shows the valid set of front Endo con;gurations for each
size variant, labeled A through R.
Figure 2.6 - Valid Endo Con$gurations (Front)
2.3.
Design Language
The design language is a set of design elements used to visually communicate a speci;c
aesthetic. Implementing a consistent design language ensures that every Ara phone has a set
of aesthetically cohesive modules, even though each phone may include modules from
diGerent sources.
January 8, 2015
Page 25 of 107
2.3.1. Geometric Design Language - Speci$cation

The overall goal of the module aesthetic is to create a smooth, Qat, pebble form. The reasons
for this aesthetic are as follows:
1. A softer form without sharp lines and edges is simple, iconic, and visually easy to
understand
2. The shape enables modules to easily slide into a module slot
3. The form of the module is one that is friendly to hold and enjoyable to handle
The design language can be articulated as a set of geometric and color, material, ;nish (CMF)
guidelines. Table 2.2 summarizes these geometric guidelines.
Table 2.2 - Design Language Geometric Guidelines
Guideline
Illustration
Module side pro;le must conform to the

shape of the Endo. This is not only
necessary to follow the design language,
but is also critical to allow the modules to
slide into module slots in the Endo and
lock into place.
Modules with components taller in Z which
occupy most of the X and Y dimensions
should continue the trapezoid form while
expanding in Z.
January 8, 2015
Page 26 of 107
Modules with localized components taller

in Z should have localized Z growths with
soft transitions to reflect the notion of a
smooth pebble form.
The side pro;le sections should be

symmetric across X and Y axes.
Corners should have 1.5 mm curvature

radii.
January 8, 2015
Page 27 of 107
Modules should keep rectilinear footprints

when possible; these are exempli;ed by
1.5 mm rounded corners connected by
straight lines.
2.3.2. Geometric Design Language - Reference Implementation

Section 3 provides example applications of the Ara design language including references to
CAD models for module templates and custom enclosures that meet the Ara design language
speci;cations.
2.3.3. Color Material Finish - Speci$cation

Color, material, and ;nish (CMF) speci;cations ensure a uniform and consistent look and feel
across all Ara modules. CMF speci;cations generally focus on externally visible components
as those components have the most impact on the end-users experience.
Modules are composed from three main sub-assemblies as detailed in the Mechanical and
Layout section: the module base, printed circuit board (PCB), and shield. The module base
(includes main Aluminum piece and Hiperco-50 inserts), the interface block PCB, and module
shells are externally visible to the end-user and must adhere to the CMF guidelines as de;ned
in Table 2.3
January 8, 2015
Page 28 of 107
Table 2.3 - Design Language CMF Speci$cations

Module Component
(Exposed Sections)
CMF Speci$cations
Aluminum Base
Color: Natural Silver (clear anodize)

Material: Anodized Aluminum
Finish: Satin (Mold Tech 11005)
Hiperco-50 Inserts
Color: Bright Satin Nickel plate

Material: Hiperco
Finish: Satin (Mold Tech 11005)
Interface Block PCB
Color: Pantone Matching System (PMS) Black C

Material: FR-4 PCB
Finish: Matte Black, Liquid Photo Imageable Solder Mask
Shells and Buttons
Color: Base White clear topcoat (for dye sublimation printing)

Material: Injection-molded polycarbonate plastic
Finish: Satin (Mold Tech 11005) or high gloss
2.3.4. Color Material Finish - Prototype Reference Implementation

The prototype system design artifacts in the Mechanical and Layout section provide
examples of compliant reference implementations of module bases and PCBs. The prototype
interface block design is diGerent than the objective system. Instead of inductive pads as
shown in Figure 2.5, the prototype interface block uses electrical contacts for data
connections. These contacts are made from copper traces with 30 microns gold plating. See
the drawings in the reference materials for exact dimensions.
January 8, 2015
Page 29 of 107
3.
Mechanical and Layout
This section de;nes mechanical speci;cations and general layout for Ara modules.
3.1.
Module Geometry and Assemblies
3.1.1. Rear Module Sub-Assemblies

3.1.1.1.
Rear Module Sub-Assemblies - Speci;cation
All three rear module types are composed of three sub-assemblies: the module base, printed
circuit board (PCB), and shield. Figure 3.1 shows an exploded view of these sub-assemblies for
a 1x2 module.
Figure 3.1 - Rear Module Sub-assemblies
As described in Section 2, the module shell is not considered part of the module assembly. To
the extent that it may deviate from a standard shell geometry, it will be created in accordance
with a module developers geometric speci;cations, but will include a consumers aesthetic
customizations and is presently envisaged to be manufactured as part of the ful;llment
process (i.e., not by the module developer).
January 8, 2015
Page 30 of 107
The module base must be composed of a piece of machined anodized Aluminum and one or
two pieces of Hiperco-50 inserts (1x1 modules have a single Hiperco-50 insert). Hiperco-50 is
an alloy with enhanced magnetic properties and thus enhanced holding force between
modules and the Endo. The inserts must mount to the sections of the module base that
correspond to the locations of electro-permanent magnets (EPMs) on the Endo. When
activated, EPMs in tandem with the Hiperco-50 inserts should provide suTcient magnetic force
to secure modules into their slots on the Endo throughout all nominal usage scenarios. When
released, EPMs provide a residual magnetic force suTcient to prevent modules from falling out
unless the user deliberately removes a module from the Endo. Users should be able to remove
modules with minimal eGort when the EPM is in the release state. EPMs require no sustained
electrical power in either attach or release states and only a short electrical pulse to transition
between states.
Except for cutouts needed for external interfaces (e.g., USB connector), the external
dimensions of the module base must conform to the shape de;ned by the CAD model and
drawings provided in the reference materials. This requirement ensures the module is
compatible with third-party provided module shells and ;ts snugly into the Endo frame.
Custom milled cavities are allowed in the inside of the module base as long as the structural
integrity of the module base is maintained and can survive module compliance speci;cations,
provided in a later section.
Figure 3.2 shows renders of the prototype 1x2 module base. Due to machining constraints,
prototype module bases include additional thin Aluminum pieces (GM 145 wrought aluminum
alloy) that are laser-welded to the inside of the main Aluminum base. These mounting inserts
provide additional surface area to adhere to the Hiperco-50 inserts.
January 8, 2015
Page 31 of 107
Figure 3.2 - Prototype Module Base
The PCBs (interface block PCB and main PCB) contain the circuitry for the module, including
circuits to enable interfaces to the Endo, as well as custom circuitry of the module. Any nonelectronic components that are part of the module (e.g., batteries, sensors) must either mount
to or be in place of the PCB. Table 3.1 provides maximum dimensions available for rear module
PCBs. PCBs smaller than these dimensions are allowed. The main PCB must be securely
mounted to the module base suTciently to survive vibration and shock speci;cations de;ned
in the Module Compliance section. A smaller PCB for the interface block should be soldered to
bottom of the main PCB and must conform to the shape and dimensions in the reference
implementation to ;t Qush with the corresponding cutout in the module base.
January 8, 2015
Page 32 of 107
Table 3.1 - Rear Module Maximum PCB Dimensions

Rear Module
PCB Maximum Dimensions (X, Y)
1x1
16.2 mm x 16.5 mm
1x2
16.5 mm x 39.15 mm
2x2
39.5 mm x 39.5 mm
Figure 3.3 shows renders of the 1x2 WiFi/BT Module main PCB and interface block PCB. The
main PCB should include the set of circuits and components needed by a generic prototype
module including a Bridge ASIC or equivalent. The module templates section provides
reference materials including a detailed Bill-of-Materials for the minimal set of components
needed for a module.
The prototype interface block PCB should implement the prototype interface block design
de;ned in a later section. The interface block PCB should be soldered to the main PCB and
adhere to the dimensions de;ned in the CAD models and 2D line drawings in the module
templates section. The interface block PCB should have the same thickness as the module
base to mount completely Qush in the opening of the module base. A 30 m gold plating
must be applied to all 12 interface block contacts.
January 8, 2015
Page 33 of 107
Figure 3.3 - Prototype 1x2 PCB
A shield is necessary to prevent users from making unintentional contact with sensitive
components on the PCB while changing module shells. The shield also acts as a Faraday cage
to protect modules from potential interference and ensure a uniform RF environment for
modules which are intentional RF emitters. The shield must be made of nickel-plated steel or a
functionally and aesthetically similar metal. Cutouts for components that exceed the standard
envelope are allowed (e.g., camera lens). The shield must securely mount to the module base.
Figure 3.4 shows a render of the prototype 1x2 WiFi/BT Module shield and PCB. The shield
is mounted to the PCB with 3 (minimum of 2) SMT-mounted clips (EMI STOP Corp SUL1320A1M). While the clips are not strictly required, they enable developers to remove and
reinstall the shield in order to access PCB components for debugging purposes. The shield
should nominally be installed during module operation and otherwise adhere to the
speci;cations de;ned in the objective system.
January 8, 2015
Page 34 of 107
Figure 3.4 - Prototype Shield and Clips
January 8, 2015
Page 35 of 107
3.1.1.2.
Rear Module Sub-assemblies - Prototype Reference Implementation
Table 3.2 provides a vertical stack up of various layers in prototype rear modules including
dimensions available for PCB components.
Table 3.2 - Prototype Rear Module Z Dimension Stack Up
Layer
Thickness
Notes:
Module Shell
0.65 mm
Not part of module, provided by module shell developer
Air Gap
0.1 mm
Thermal insulation
Shield
0.2 mm
Clearance
1.55 mm
Available for PCB component
PCB
0.6 mm
FR-4 PCB
Insulation/Adhesive
0.05 mm
E.g., Glue. Area is not available where interface block

mounts to PCB.
Module Base/Interface
Block PCB
0.85 mm
Interface block PCB should mount Qush to the module

base opening
Total Module Thickness
4.0 mm
The following subsections provide reference implementations of several prototype rear

modules.
3.1.1.2.1.
Rear Module Templates - Prototype Reference Implementation
Table 3.3 provides relative ;le paths to design artifacts to create a minimal instantiation of
prototype rear modules. The module templates include both mechanical and electrical
models. The mechanical model includes 3D CAD models in STEP format and additional 2D
line drawings. Hiperco-50 inserts on the prototype modules are attached to the module base
with 3M Scotch-WeldTM Epoxy Adhesive DP100 Plus Clear, while the PCB is attached to the
module base with Hitachi Kasei Polymer Hi-PURSHOT 9753 adhesive.
Electronic design automation (EDA) ;les are in Allegro format (DSN for schematics and BRD
for layout). The template also includes EDA output packages, which contain schematics in
pdf format and bill-of-materials (BOM).
The module template EDA and output ;les include the Toshiba GP Bridge ASICs that handles
module communications and other system-level functions. The ASICs provide bridging of
several interface protocols that module developers can use to communicate with an
Application Processor (AP) in the AP module or on the AP development board. The Network
Stack section of this document details these protocols.
January 8, 2015
Page 36 of 107
Table 3.3 - Prototype Rear Module Templates

Prototype Rear Module
Design Artifacts
Prototype 1x1 Module
3D Models and Drawings:

ReferenceMaterials\1x1\Prototype1x1ModuleTemplate\CADFiles
EDA File and Outputs:
ReferenceMaterials\1x1\Prototype1x1ModuleTemplate\EDAFiles


3.1.1.2.2.
1x2 Camera Module - Prototype Reference Implementation
Table 3.4 provides relative ;le paths to design artifacts to create the prototype Camera
Module in a 1x2 module template.
Table 3.4 - 1x2 Prototype Camera Module Reference Implementation
Module
Design Artifacts
Prototype Camera
Module

ReferenceMaterials\1x2\PrototypeCameraModule\CADFiles
ReferenceMaterials\1x2\PrototypeCameraModule\EDAFiles
3.1.1.2.3.
1x2 Speaker Module - Prototype Reference Implementation
Table 3.5 provides relative ;le paths to design artifacts to create the prototype Speaker
Module in a 1x2 module template.
Table 3.5 - 1x2 Prototype Speaker Module Reference Implementation
Module
Design Artifacts
Prototype Speaker
Module

ReferenceMaterials\1x2\PrototypeSpeakerModule\CADFiles
ReferenceMaterials\1x2\PrototypeSpeakerModule\EDAFiles
January 8, 2015
Page 37 of 107
3.1.1.2.4.
2x2 Marvell AP Module - Prototype Reference Implementation
Table 3.6 provides relative ;le paths to design artifacts to create the prototype Marvell AP
Module with GPS in a 2x2 module template. The AP Module incorporates a GPS antenna in
the module shell. See the Antenna section below for details on antenna and antenna
interface speci;cations and reference implementations. The AP module includes a USB
connector to facilitate direct access to the AP for diagnostics and debugging purposes.1 The
USB connector does not provide power.
Table 3.6 - 2x2 Prototype Marvell AP Module Reference Implementation
Module
Design Artifacts
Prototype Marvell AP
Module

ReferenceMaterials\2x2\PrototypeMarvellAPModule\CADFiles
ReferenceMaterials\2x2\PrototypeMarvellAPModule\EDAFiles
3.1.1.2.5.
2x2 NVidia AP Module - Prototype Reference Implementation
Table 3.7 provides relative ;le paths to design artifacts to create the prototype NVidia AP
Module in a 2x2 module template. The AP Module incorporates a GPS antenna in the module
shell. See the Antenna section below for details on antenna and antenna interface
speci;cations and reference implementations. The AP module includes a USB connector to
facilitate direct access to the AP for diagnostics and debugging purposes. The USB
connector does not provide power.
Table 3.7 - 2x2 Prototype NVidia AP Module Reference Implementation
Module
Design Artifacts
Prototype NVidia AP
Module

ReferenceMaterials\2x2\PrototypeNVidiaAPModule\CADFiles
ReferenceMaterials\2x2\PrototypeNVidiaAPModule\EDAFiles
1In future MDK releases, AP modules may be required to have a USB or another external connection for certain
debug scenarios. This is not a requirement of the current MDK release.
January 8, 2015
Page 38 of 107
3.1.1.3.
Hiperco-50 - Known Vendors
Hiperco-50 inserts are available from Foxconn Interconnect Technology (FIT) or in raw form
from vendors listed in Table 3.8.
Table 3.8 - Hiperco-50 Known Vendors
Vendor
Product
Foxconn Interconnect
Ara Module Hiperco-50 inserts
Ed Fagan & Associate
Hiperco-50 alloy in strip/coil or sheets
Carpenter Steel
Hiperco-50 in large quantities
3.1.2. Front Module Sub-assemblies

3.1.2.1.
Front Module Sub-assemblies - Speci;cation
Figure 2.6 shows the possible distinct front module (A-R). While all front modules require a
module base and PCB for mounting the interface block(s), the other sub-assemblies are
speci;c to the module. As an example, a Display Module may have a display, touch sensor,
and glass cover. Table 3.6 provides outer dimensions and dimensions available for a PCB in
the two front modules in the current prototype. Maximum PCB dimensions for the other
modules will be provided in a future MDK release.
January 8, 2015
Page 39 of 107
Table 3.9 - Front Module Outer Dimensions and PCB Dimensions

Front Module (Endo Size)
Module Outer Dimensions (X, Y)
Maximum PCB Dimensions (X, Y)
A (Mini)
45 mm x 114 mm
TBD
B (Mini)
45 mm x 20 mm
TBD
C (Mini)
45 mm x 91 mm
TBD
D (Mini)
45 mm x 68 mm
TBD
E (Mini)
45 mm x 68 mm
TBD
F (Mini)
45 mm x 46 mm
TBD
G (Medium)
67.74 mm x 136.87 mm
TBD
H (Medium)
67.74 mm x 14.74 mm
62.2 mm x 9.5 mm
I (Medium)
67.74 mm x 120.74 mm
52.2 mm x 90 mm
J (Medium)
67.74 mm x 104.25 mm
TBD
K (Medium)
67.74 mm x 75.02 mm
TBD
L (Medium)
67.74 mm x 44.81 mm
TBD
M (Jumbo)
90.74 mm x 169.74 mm (TBD)
TBD
N (Jumbo)
90.74 mm x 14.74 mm (TBD)
TBD
O (Jumbo)
90.74 mm x 143.74 mm (TBD)
TBD
P (Jumbo)
90.74 mm x 127.74 mm (TBD)
TBD
Q (Jumbo)
90.74 mm x 111.74 mm (TBD)
TBD
R (Jumbo)
90.74 mm x 30.74 mm (TBD)
TBD
January 8, 2015
Page 40 of 107
3.1.2.2.
Front Module Sub-assemblies - Prototype Reference Implementation
Table 3.10 provides a vertical stack up of various layers in a front module including
dimensions available for PCB components, displays, glass, and other components that are
typically found on the front of a phone.
Table 3.10 - Prototype Front Module Z Dimension Stack Up
Layer
Thickness
Notes:
Module Shell
0.65 mm
Air Gap
0.1 mm
Thermal insulation
Clearance
0.1 mm
E.g., Mesh for receiver speaker
Shield
0.15 mm
Clearance
1.7 mm
Available for module component
PCB
0.4 mm
FR-4 PCB
Insulation/Adhesive
0.05 mm
E.g., Glue
Module Base/Interface
Block PCB
0.85 mm
Interface block PCB should mount Qush to the module

base opening
Total Module Thickness
4.0 mm
3.1.2.2.1.
Receiver Module - Prototype Reference Implementation
The current prototype implementation includes two front modules, both for the Medium Endo
variant. There is a Receiver Module (Class H) and a Display Module (Class I). Table 3.11
provides relative ;le paths to design artifacts to create a prototype Receiver Module. In
addition to the receiver speaker, the Receiver module includes a proximity sensor and light
sensor.
Table 3.11 - Prototype Receiver Module Reference Implementation
Component
Design Artifacts
Receiver
Module

ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\CADFiles
ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\EDAFiles
January 8, 2015
Page 41 of 107
3.1.2.2.2.
Display Module - Prototype Reference Implementation
Table 3.12 provides relative ;le paths to design artifacts to create a prototype Display Module
with touch interface, microphone, power, and volume buttons.
Table 3.12 - Prototype Display Module Reference Implementation
Component
Design Artifacts
Display
Module

ReferenceMaterials\ClassI(Medium)\PrototypeDisplayModule\CADFiles
ReferenceMaterials\ClassI(Medium)\PrototypeDisplayModule\EDAFiles
3.1.3. Module Label

3.1.3.1.
Module Label - Speci;cation
The back of every module must have a clearly marked module label. This label must include
the Ara emblem, the name of the module developer, the name of the module, and a module
icon signifying the module function. The Ara emblem, module icons, and application
instructions will be provided in a future MDK release. If applicable, module labels should
include regulatory markings such as the module FCC ID and CE markings.
Figure 3.5 de;nes the speci;cations for positioning text and icons in the module label in
relation to the interface block. If a module has multiple interface blocks, the module label must
be positioned in relation to the leftmost interface block as viewed from the direction in Figure
3.5. Module labels should be applied with a laser-etched process.
January 8, 2015
Page 42 of 107
Figure 3.5 - Module Label Speci$cations
3.1.3.2.
Module Label - Prototype Reference Implementation
Module labels are not required for prototypes.
3.1.4. Envelope Violation Limitations

3.1.4.1.
Envelope Violation - Speci;cation
The envelope for a module comprises the standard dimensions for the module to conform to
the Ara Endos. While a module will ideally ;t within these very speci;c dimensions, modules
are allowed to exceed the standard envelope in the Y (top-bottom) and Z (thickness) directions.
Modules are NOT allowed to exceed the envelope in the X (side-side) direction. Table 3.13
provides the absolute maximum exceedance limits; however, module developers should also
January 8, 2015
Page 43 of 107
use good engineering judgement to determine the stress levels from user levied forces and
torques and ensure exceedances are structured to accommodate common usage scenarios
including scenarios where the module and phone are in the users pocket. Future releases of
the MDK may be more restrictive in exceedance limits based on results of handling and
accelerated lifecycle testing. Modules with dimensional exceedances must have a custom
shield and ensure all electrically active components except antennas and batteries are
encapsulated within.
Table 3.13 - Envelope Violation Limits
Direction
Max Dimension
Notes
45 mm (Mini), 67.02 mm
(Medium), 21.82 mm (1x1,
1x2), 44.82 mm (1x2, 2x2)
Modules are NOT allowed to exceed the standard

envelope in the X direction.
20 cm
Overall module height must not exceed this ;gure.
2.6 cm
Overall module thickness must not exceed this ;gure.
Whenever modules exceed the standard envelope, the exceedance should conform to the Ara
design language speci;cation (in Section 2).
3.1.4.2.
Envelope Violation - Reference Implementation
Exceedances may be appropriate and necessary for some applications as demonstrated in
Figure 3.6. Figure 3.6 shows a reQective Pulse Oximeter Module, which measures blood
oxygen saturation. The exceedance in the Y dimension provides a convenient aGordance and
sensor location for a users ;nger.
January 8, 2015
Page 44 of 107
Figure 3.6 - Pulse Oximeter Module with Y-Dimension Exceedance
January 8, 2015
Page 45 of 107
3.1.4.3.
Envelope Violation - Prototype Reference Implementation
Figure 3.7 shows several examples of modules that exceed the standard envelope. The
exceedances in the Z dimension for the Camera, USB Charger, and Extended Battery
Modules enable each to accommodate components (camera lens unit, charge port, and
battery respectively) with higher thickness requirements than is aGorded in the standard
envelope.
Figure 3.7 - Modules with Z-Dimension Exceedances
Figure 3.8 demonstrates a compliant custom module shell for the prototype Camera Module.
The shell has a raised opening for the lens. CAD ;les and line drawings of the custom
Camera Module Shell is provided in the reference materials.
January 8, 2015
Page 46 of 107
Figure 3.8 - Custom Module Shell for Prototype Camera Module
3.1.4.4.
1x2 Pollution Sensor Module - Prototype Reference Implementation
Table 3.14 provides relative ;le paths to design artifacts to create the prototype Pollution
Sensor Module in a 1x2 module template. The Pollution Sensor Module exceeds the
standard envelope but remains within the envelope limits.
Table 3.14 - Prototype Pollution Sensor Module Reference Implementation
Component
Design Artifacts
Pollution
Sensor
Module

ReferenceMaterials\1x2\PrototypePollutionSensorModule\CADFiles
ReferenceMaterials\1x2\PrototypePollutionSensorModule\EDAFiles
3.2.
Connectors
The following subsections de;ne the connectors on Ara modules. All modules require at least
one interface block to exchange power, data, and detect/wake signal between modules and
the Endo. Some modules may also send RF signals through the interface block to another
module on the device. Modules require Hiperco-50 insert(s) on the module base to provide
enhanced magnetic coupling with the EPMs in the Endo. Front modules also require an
additional spring loaded mechanism attached to the Hiperco-50 insert that work in tandem
January 8, 2015
Page 47 of 107
with EPMs in the Endo to secure the module in place when activated. Finally, ;nger-nail slots in
the module base allow users to remove and replace module shells.
3.2.1. Interface Block

The interface block hosts electrical, data, and RF connections between modules and the Endo.
The Ara platform utilizes a contactless inductive interface for high-speed data transfer between
modules and the Endo. The Network Stack section details the contactless data transfer
mechanism.
3.2.1.1.
Interface Block - Speci;cation
Each interface block is composed of 4 electrical connections (2 for power, 1 detect/wake, and
1 RF) and 8 data interfaces transferred by means of 4 contactless inductive pads as shown in
Figure 3.9 (1x2 modules have 2 sets of electrical connections to enable module insertion in
both orientations). Details of the contactless inductive interface is provided in the Network
section. Additional details of the objective interface block design will also be provided in a
future MDK release.
Figure 3.9 - Interface Block with Inductive Pads
The interface block is itself mounted and printed on a separate PCB. The interface block PCB
is then soldered to the main PCB. When installed into the module, the interface block PCB
should be completely Qush with the corresponding opening in the module base. The interface
block PCB must follow the geometry speci;ed in the module template CAD and EDA ;les
provided in the reference implementation.
January 8, 2015
Page 48 of 107
3.2.1.2.
Interface Block - Prototype Reference Implementation
The interface block in the current prototype platform diGers from the objective speci;cation.
Instead of contactless data transfer with inductive pads, the prototype uses electrical
signaling between the gold-plated copper pads on the module interface block and spring
pins on the Endo for data transfer (i.e., the same method used for power transfer). The shape
of the prototype interface block pad is round to match the spring pins on the Endo. The
module template section provides design artifacts for the prototype interface block reference
implementation.
The prototype interface block provides 8 data pads: two bidirectional M-PHY data lanes with
8 diGerential pairs (2 TX pairs and 2 RX pairs), a power pad, a ground pad, a detect/wake
pad, and an RF pad. Figure 3.10 and Table 3.15 detail the pinouts of the prototype interface
block.
Figure 3.10 - Prototype Interface Block Pinout

January 8, 2015
Page 49 of 107
Table 3.15 - Prototype Interface Block Pinout Descriptions

#
Pin/Pad Label
Description
RF
RF Signal
DET/WAKE
Detect/Wake Signal
VCONN
Positive Voltage Connector
MTX_D0N
M-PHY Transmit Lane 0 Negative
MTX_D0P
M-PHY Transmit Lane 0 Positive
MRX_D0N
M-PHY Receive Lane 0 Negative
MRX_D0P
M-PHY Receive Lane 0 Positive
MTX_D1P
M-PHY Transmit Lane 1 Positive
MTX_D1N
M-PHY Transmit Lane 1 Negative
10
MRX_D1P
M-PHY Receive Lane 1 Positive
11
MRX_D1N
M-PHY Receive Lane 1 Negative
12
GND
Ground
3.2.1.3.
Front Module Attachment - Speci;cation
Front modules attach to the Endo with a spring-loaded Hiperco-50 insert and are secured with
an EPM on the Endo. The ribs in the Endo secure front modules in the Y direction (top-bottom).
When a user slides the module into the Endo and aligns the module in the X direction (side-toside), the EPM in the Endo activates and pulls the Hiperco-50 insert into the Endo to lock the
module in place. To release and unlock a module, the user commands the EPM to release and
springs the Hiperco insert back into the module.
The front module attachment spring should have a spring force constant in the order of 1
N/mm to provide optimum release force when the EPM is deactivated, while not exceeding the
ability of the EPM to pull the insert into the Endo when activated. The dimensions of the
Hiperco-50 insert should conform to the shape de;ned by the CAD model and drawings
provided in the reference materials. In the release state, the Hiperco insert must be Qush with
the module base.
January 8, 2015
Page 50 of 107
3.2.1.4.
Front Module Attachment - Prototype Reference Implementation
Front module attachment prototype reference implementations are provided in the reference
materials for the Prototype Display and Receiver Modules. Figure 3.11 shows a closeup view
of the front module attachment mechanism in the Prototype Receiver Module.
Figure 3.11 - Closeup View of Front-Module Attachment Assembly
January 8, 2015
Page 51 of 107
3.3.
Antennas
Antennas can be installed inside a module, outside the shield (i.e. on top of the shield), or as
part of the module shell. Modules may also route RF signals to a diGerent module on the phone
using the RF connector on the interface block and the RF bus in the Endo. The following subsections provide speci;cations and reference implementations for each scenario.
3.3.1. Antenna in Module - Speci$cation

Module developers may design an antenna within a module, outside of the shield. Antennas
may be connected to components in the module PCB through any suitable means as long as
all electrically active components on the PCB are still covered by the shield. Slots in the shield
are allowed for antenna connectors.
Module developers may also design antennas directly into the module shell as shown in Figure
3.12. In this scenario, developers should design an antenna pattern that leverages laser direct
structuring (LDS) method to create antennas directly on the polycarbonate plastic module shell.
Several prototype modules provided in the subsequent reference implementation sections
include LDS antenna patterns as examples. All custom shells, including those with LDS
antennas should be ful;lled as part of the user aesthetic customization process, independent
of the module developer.
Figure 3.12 - Example of Antenna Pattern on Module Shell
January 8, 2015
Page 52 of 107
3.3.2. 1x2 WiFi/BT Module with Antenna - Prototype Reference Implementation

Table 3.15 provides relative ;le paths to design artifacts to create the prototype WiFi/BT
Module in a 1x2 module template. The WiFi/BT Module incorporates an antenna in the
module shell manufactured with an LDS method. The antenna was designed and optimized
using automated methods including the use of a genetic algorithm, which used RF and
geometric speci;cations to generate suitable designs. The antenna is connected to the main
PCB using one ground and one RF signal spring contact. Details of the assembly are
provided in the reference materials in Table 3.16.
Table 3.16 - 1x2 Prototype WiFi/BT Module Reference Implementation
Module
Design Artifacts
Prototype WiFi/Bluetooth
Module

ReferenceMaterials\1x2\PrototypeWiFiModule\CADFiles
ReferenceMaterials\1x2\PrototypeWiFiModule\EDAFiles
3.3.3. Antenna Interface - Speci$cation

The Endo enables modules to route RF signals to other modules on the device. This feature
allows diversi;cation of antenna placement and specialized antenna modules (e.g., antenna
modules that combine multiple frequency bands). RF signals can be routed through the RF
connector in the interface block to an RF bus in the Endo. Modules should treat the RF signal
through the Endo as a 50 transmission line.
January 8, 2015
Page 53 of 107
3.3.4. Antenna Interface - Prototype Reference Implementation

The RF bus can currently route signals between module slots in the top half and bottom half
of the prototype Endo only, as shown in Figure 3.13. The prototype system uses the RF bus
in the Endo to route Band 5 RF signals between a 1x2 3G cellular modem in the 3G Cellular
Module to a 1x1 Antenna Module that houses a Band 5 antenna incorporated into the
module shell. The subsections below provide links to reference materials necessary to create
the Prototype 3G Cellular and Antenna Modules.
Figure 3.13 - RF Bus in Endo Enables Routing Between Modules on Top and Bottom Halves
3.3.4.1.
1x2 3G Cellular Module - Prototype Reference Implementation
Table 3.17 provides relative ;le paths to design artifacts to create the prototype 3G Cellular
Module in a 1x2 module template. The 3G Cellular Module has a Band 2 antenna
incorporated into its module shell using the same method used on the WiFi/BT Module. The
3G Cellular Module also routes a Band 5 RF signal from the 3G modem to the RF pad on the
interface block. The RF signal is routed to the Antenna Module de;ned in the next
subsection.
The Prototype 3G Cellular Module currently has several excursions from the MDK
speci;cations including a modi;ed module base (it does not have Hiperco-50 inserts and
uses a diGerent metal) and a modi;ed interface block design to create suTcient space for the
January 8, 2015
Page 54 of 107
cellular modem module. Developers should follow the module templates for reference
implementations that are fully compliant with the MDK speci;cations. An MDK-compliant
reference implementation of the 3G Cellular Module will be provided in a future MDK release.
Table 3.17 - 1x2 Prototype 3G Cellular Module Reference Implementation
Module
Design Artifacts
Prototype 3G Cellular
Module

ReferenceMaterials\1x2\Prototype3GCellularModule\CADFiles
ReferenceMaterials\1x2\Prototype3GCellularModule\EDAFiles
3.3.4.2.
1x1 Antenna Module - Prototype Reference Implementation
Table 3.18 provides relative ;le paths to design artifacts to create the prototype Antenna
Module in a 1x1 module template. The Antenna Module contains a 3G Band 5 antenna on
the module shell made using the same method as described in the WiFi/BT Module. The 3G
Band 5 antenna is connected to the Prototype 3G Cellular Module through the RF switch in
the Endo.
Table 3.18 - 1x1 Prototype Antenna Module Reference Implementations
Module
Design Artifacts
Prototype Antenna
Module

ReferenceMaterials\1x1\PrototypeAntennaModule\CADFiles
ReferenceMaterials\1x1\PrototypeAntennaModule\EDAFiles
January 8, 2015
Page 55 of 107
4.
Power
This section de;nes power speci;cations and reference implementations for Ara modules. The
Ara power architecture is designed to accommodate the unique and Qexible nature of the
platform. Users of an Ara phone will be able to power their device with one or multiple
batteries; they will be able to swap a depleted battery with a fresh one, without powering oG
their phone; they will be able to charge one or more batteries in their phone from one or
multiple charging devices. The design of the power architecture enables all of these use cases
and provides a Qexible power platform for new applications.
Figure 4.1 shows a high-level view of the Ara power architecture. A common power bus is
central to the architecture. The power bus voltage is speci;ed to be between 3.3 and 4.8 V. The
power bus is distributed through the Endo frame to each interface block. A power manager in
the Endo optimizes power consumption, reduces current leakages, and provides protection
against overcurrents and overvoltages. The Endo also has a small battery or capacitor bank,
and associated charge controller. The power stored in the Endo provides power to the phone
during brief periods when the battery and/or charger modules are being hot-swapped or
recon;gured and no other power source is available to keep the device on.
Ara modules fall into three categories in relation to the power architecture: power consumers,
charging modules, and power storage modules (batteries, fuel cells, etc.). Modules can change
categories throughout their usage life. For instance, a battery module may have a built-in
charging port. Such a module would serve as a power consumer when being charged from the
bus (e.g., if another modules charging port is active), a charging module when powered
through its charging port, and a power storage device when functioning as a regular battery.
Figure 4.1 also illustrates a simpli;ed view of these three module types. The following
subsections describe each of the types.
January 8, 2015
Page 56 of 107
Figure 4.1 - Power Architecture
4.1.
Power Consumer Module - Speci$cation
At the top of Figure 4.1 is a power consumer module, which is the simplest in its operation. The
power consumer module draws power directly from the power bus, or more commonly, voltage
regulator(s) steps down and regulates the voltage from the bus for various circuits within the
module.
4.2.
Power Consumer Module - Prototype Reference Implementation
There are multiple power consuming modules in the prototype system. Design artifacts for
these modules are provided in the Mechanical and Layout section.
January 8, 2015
Page 57 of 107
4.3.
Charger Module - Speci$cation
Charging modules can supply externally derived power to the power bus. Charging modules
may draw a small amount of current from the power bus during module initialization, but
current Qows nominally in one direction, from the module to the bus. Figure 4.1 shows a
traditional DC charger module.
4.4.
USB Charger Module - Prototype Reference Implementation
Table 4.1 provides relative paths to design artifacts to create a USB Charger Module in a 1x1
module template. The USB Charger Module uses a standard USB Micro-B socket. An
external power supply provides USB compliant DC power. The Prototype USB Charger
Module currently provides power only; it does not provide a data interface.
Table 4.1 - 1x2 Prototype USB Charger Module Reference Implementation
Component
Design Artifacts
USB Charger
Module

ReferenceMaterials\1x1\PrototypeUSBChargerModule\CADFiles
ReferenceMaterials\1x1\PrototypeUSBChargerModule\EDAFiles
4.5.
Power Storage Module - Speci$cation
Power storage modules primarily include battery modules, but other power storage devices are
envisioned. Power storage modules can supply power to the rest of the system or draw power
from the bus for recharging.
Battery modules supply power to the power bus by default. Figure 4.2 shows a con;guration in
which there are multiple battery modules connected to the power bus. Ideal diode circuits are
required to prevent current Qow into a battery in default discharge mode. The power bus
voltage is equal to the highest voltage presented by any of the batteries connected to the
power bus; the battery with the highest voltage bears the full load. The load is shared when
the voltage falls to level of the next highest battery. This trend continues until the voltage
across all batteries is equal and the load is shared evenly among them.
January 8, 2015
Page 58 of 107
Figure 4.2 - Power Bus Voltage With Multiple Battery Modules
Figure 4.3 shows when a charger module is connected to the system and ready to deliver
charging current to the batteries, it signals the supervisory controller in the Endo (power
manager) via UniPro messaging. The supervisory controller then signals battery modules to cut
oG power delivery to the power bus and activate their charging circuits to draw power from the
bus. The supervisory controller periodically polls battery modules to report self diagnostics
such as state of charge and uses this information in its power management routines. Power
storage modules must declare their total capacity and report their remaining capacity to the
Endo to ensure the power manager can accurately determine the overall power budget of the
device.
January 8, 2015
Page 59 of 107
Figure 4.3 - Battery Charging
January 8, 2015
Page 60 of 107
4.6.
Battery Modules - Prototype Reference Implementation
There are two prototype Battery Modules. Both use lithium-ion battery packs. The Extended
Battery Module has a larger battery pack that necessitates exceeding the standard 4 mm
module height envelope. Both battery modules are designed with a voltage regulator that
holds the voltage output at 4.6 V. Table 4.2 provides relative paths to design artifacts to
create each battery module in a 2x2 module template.
Table 4.2 - 2x2 Prototype Battery Module Reference Implementations
Component
Design Artifacts
Battery Module

ReferenceMaterials\2x2\PrototypeBatteryModule\CADFiles
ReferenceMaterials\2x2\PrototypeBatteryModule\EDAFiles
Extended Battery
Module

ReferenceMaterials\2x2\PrototypeExtendedBatteryModule\CADFiles
ReferenceMaterials\2x2\PrototypeExtendedBatteryModule\EDAFiles
January 8, 2015
Page 61 of 107
5.
Network Stack
5.1.
Module Communication Physical View
Figure 5.1 illustrates the interfaces that enable module to module communication on an Ara
phone. The network architecture centers around the MIPI M-PHY and UniPro protocols. MPHY and UniPro are speci;cally designed for mobile devices with advanced features to provide
high throughput with low power consumption. These protocols enable modules to
communicate with one another module through a packet-switched network in the
Endoskeleton.
Figure 5.1 - Module to Module Communication (with Native UniPro Support and Bridge ASICs)
Figure 5.1 shows various example modules: an AP module with native M-PHY and UniPro, a
Display module communicating via a UniPro-based protocol, a Camera module communicating
via CSI-3, and a Storage Module communicating via UFS (CSI-3 and UFS are both UniProcompatible MIPI standards, and other M-PHY and UniPro compliant modules are also
envisioned). Figure 5.1 shows a Medical module with a Personal Diagnostic Sensor with built-in
M-PHY and UniPro support. Modules without native M-PHY and UniPro support may utilize
General Purpose (GP) Bridge or High-Speed (HS) Bridge ASICs that intermediate between
UniPro and several standard chip-to-chip protocols including SDIO, USB, UART, I2C, I2S, and
GPIO. Each interface block provides a 2-lane bidirectional M-PORT (2 TX and 2 RX M-PHY
lanes). Some modules may have additional interface blocks (up to 2 in a 2x2 and up to 4 on a
front module), enabling up to four 2-lane bidirectional M-PORTS (or 8 M-PHY lanes total).
January 8, 2015
Page 62 of 107
The modules in Figure 5.1 connect to a UniPro switch in the Endo over a contactless media
converter, which is described in the following section. A supervisory controller in the Endo
manages its internal functions and external interfaces, including the UniPro switch, EPMs, and
Endo battery.
All prototype modules today use either Toshiba High-Speed (HS) Bridge or General Purpose
(GP) Bridge ASICs to intermediate between UniPro and several native interfaces. Developers
should note that the Toshiba Bridge ASICs are not strictly required to compose a module;
developers may use any suitable means to implement a M-PHY and UniPro compliant
interface to the Endo. Other Bridge ASICs and M-PHY/UniPro ASICs in additional to the
current Toshiba ASICs are envisioned in the future. The module templates and prototype
reference modules in the Mechanical section of the MDK describe the current Bridge ASICs
and associated circuitry to instantiate a module that can communicate over one of the
provided bridged interfaces. The list of such bridged interfaces is provided in the Network
Hardware section.
The prototype diGers from the objective system in two key aspects, as illustrated in Figure
5.2. First, the prototype uses electrical contact pads instead of contactless inductive pads.
Second, each interface block must utilize all four M-PHY lanes (2 RX and 2 TX) due to a
limitation in the current UniPro switch.
Figure 5.2 - Prototype Module to Module Communication
5.2.
Network Stack
The Ara network protocol stack is summarized in Table 5.1. The Ara network is packetswitched and based on the MIPI M-PHY and UniPro standards. The network enables high data
rate communication between modules with low pin count and low power consumption.
January 8, 2015
Page 63 of 107
Table 5.1 - Ara Network Stack

OSI Layer
Ara Implementation
Layers 5-7
Greybus subsystem, associated drivers and user-mode software
Layers 1.5-4
MIPI UniPro v1.6
Layer 1
MIPI M-PHY v3.0 with contactless media converter (CMC)
The prototype network stack diGers from the objective system is several aspects. Layer 1 is
standard MIPI M-PHY, without the contactless media converter. The current prototype also
does not yet support UniPro class drivers at Layers 5-7. The current prototype uses devicespeci;c drivers for each prototype module; these drivers use bridged PHY protocols (as
de;ned within the Greybus Speci;cation) to communicate with their associated modules.
The Software section describes Android features that expose these interfaces to higher
layers of the stack.
Table 5.2 - Prototype Ara Network Stack
OSI Layer
Prototype Ara Implementation
Layers 5-7
Android platform with support for Bridge ASIC interfaces
Layers 1.5-4
MIPI UniPro v1.6
Layer 1
MIPI M-PHY v3.0
5.2.1. Layer 1
Layer 1 includes the contactless media converter and M-PHY.
5.2.1.1.
Layer 1 Contactless Media Converter - Speci;cation
The contactless media converter (CMC) allows high-speed and contactless transmission of
data between modules and the Endo. The CMC (which can either be integrated into the M-PHY
IP block natively, into a bridge ASIC, or as a stand-alone CMC discrete component) removes
the need for a data connector, saving space and cost, and increasing durability. The Ara
platform uses contactless, inductively-coupled data communication between modules and the
Endo. This AC-coupled interface replaces the mechanical connector with traces on a printed
circuit board. This section provides an overview of the CMC. A detailed draft CMC specification
is provided in the reference materials2 (Reference Materials\Documents\CMC M-PHY Physical
Layer Speci;cation.pdf).
2Project Ara is working with the MIPI M-PHY standards committee to incorporate the CMC speci;cation as part of
the M-PHY Speci;cation. We will reference the oTcial MIPI Speci;cation as it becomes more mature.
January 8, 2015
Page 64 of 107
Figure 5.3 shows a pair of inductive loops on adjacent printed circuit boards. The lower loop is
connected to the transmitter IC, and the upper loop is connected to the receiver IC, using
microsctrip transmission lines. The two coaxial loops taken together form a signal transformer: A
time-varying current in the lower loop creates a time-varying magnetic field in air space between
the boards, inducing a time-varying voltage in the upper loop.
Figure 5.3 - Inductive Communication Between PCBs
Figure 5.4 presents a high-level view of the contactless media converter circuit. To allow lowspeed data transmission, the DC level of the signal is restored in the receiver ;rst by a variable
gain ampli;er (VGA), followed a continuous time linear equalizer (CTLE), and a hysteresis
comparator, which restore data pattern from the transmission.
Figure 5.4 - Contactless Media Converter (Inductive)
January 8, 2015
Page 65 of 107
The contactless media converter will operate over the 0.125 - 0.5 mm (+/- 0.05 mm) (TBD) airgap between the module and Endo. It will support all M-PHY transmission rates and modes
implemented by the Ara network (see M-PHY speci;cations section). See the draft CMC
Speci;cation document in the reference materials for more detailed speci;cations.
5.2.1.2.
Layer 1 Contactless Media Converter - Reference Implementation
A reference implementation for the contactless media converter is under development. The
contactless media converter will also be part of a future version of the Toshiba Bridge ASICs
and also available as a stand-alone discrete component that can be used as an add-on to a
device enabled with conventional M-PHY MPORTs.
5.2.1.3.
Layer 1 Contactless Media Converter - Prototype Reference Implementation
Current prototype modules do not use a contactless media converter. They use standard DC
M-PHY signaling through electrical contacts between modules and the Endo in the interface
block. The following describes a prototype implementation of an AC-coupled PHY on a test
bench.
We have been using the Analog Devices ADCMP582 ultrafast comparator as a capacitive
media converter for UniPro over a TMPI/LVDS surrogate PHY. With this, we have
demonstrated bidirectional Unipro data transmission at 800 Mb/sec, as well as clock
transmission from 1 Hz through 1.8 GHz.
The key feature of this chip that makes it work in this application is its resistor-programmable
input hysteresis, which allows even low-frequency square wave signals to be received
through the capacitive channel so long as they have fast edges.
5.2.1.4.
Layer 1 MIPI M-PHY - Speci;cation
The Ara network stack uses MIPI M-PHY (V3.0 26-July-2013) at Layer 1. M-PHY is a serial
interface that supports multiple transmission rates for high and low bandwidth applications. MPHY uses 8b/10b encoding and an embedded clock signal. M-PHY also has multiple power
saving modes to support low power embedded devices.
M-PHY operating with the contactless media converter de;ned in the previous section can
support up to HS-GEAR 3 (at 3A/3B Bandwidth and 4.99/5.82 Gbps per lane) and PWM-GEAR
1 to PWM-GEAR 2 (at 9/18 Mbps per lane).
5.2.1.5.
Layer 1 MIPI M-PHY - Reference Implementation
A module can implement MIPI M-PHY in multiple ways. One example is to use the Bridge
ASICs de;ned in the Network Stack Hardware section below. Module developers may also
instantiate M-PHY with IP cores that are available from the M-PHY known vendors section, or
develop a M-PHY implementation directly from the MIPI speci;cations.
January 8, 2015
Page 66 of 107
5.2.1.6.
Layer 1 MIPI M-PHY - Known Vendor(s)
MIPI M-PHY IP cores are available from vendors listed in Table 5.3.
Table 5.3 - MIPI M-PHY Known Vendors
Vendor
Product
Mixel
MXL-M-PHY-MIPI M-PHY 3.0 IP
Synopsys
DesignWare MIPI M-PHY 3.0 IP
Arasan
M-PHY 3.0 Analog Transceiver IP
5.2.1.7.
Layer 1 M-PHY - Prototype Reference Implementation
Layer 1 MIPI M-PHY speci;cations are implemented on prototype modules with Toshibas
Bridge ASICs. The current ES1 Bridge ASICs provides 2 RX and 2 TX M-PHY lanes that
connects to the UniPro switch in the Endo. See the Network Hardware Section below. New
versions (ES2 and ES3) of the UniPro Switch and Bridge ASICs will enable modules to utilize
a single RX or TX lane if desired.
5.2.1.8.
Layer 1 D-PHY - Prototype Speci;cation
The prototype system utilizes D-PHY (V1.1 7-November-2011) to support CSI-2 and DSI
interfaces for camera and display data respectively. D-PHY interfaces should be localized
between components on the module only. The interface between modules and the Endo
uses M-PHY as de;ned in the previous sections.
D-PHY uses 2 wires for a clock signal, and multiple wire pairs for data transfer between a
master and slave, typically between a host processor/bridge and camera/display devices
respectively.
5.2.1.9.
Layer 1 D-PHY - Prototype Reference Implementation
Layer 1 MIPI D-PHY speci;cations are implemented on the prototype AP, Camera, and
Display modules with a Toshiba HS Bridge ASIC. The HS Bridge provides 8 D-PHY data
lanes and 2 clock lanes to support up to 4 CSI-2 and 4 DSI data lanes. More detailed
information on the HS Bridge ASIC is provided in the Network Hardware section and
corresponding references.
5.2.2. Layers 1.5-4

5.2.2.1.
Layers 1.5-4 MIPI UniPro - Speci;cation
The Ara network stack uses MIPI UniPro (V1.6 6-August-2013) at the data link, transport, and
network layers3. UniPro is designed speci;cally for mobile applications and enables a
lightweight, low-latency packet-switched network between modules on an Ara phone. A
3Project Ara is working with the MIPI UniPro standards committee to de;ne a standard implementation of strong
cryptographic protection for information transmitted over the UniPro bus, which may be incorporated in a future
MDK release as it becomes more mature.
January 8, 2015
Page 67 of 107
UniPro switch in the Endo routes packets between modules and provides quality of service
guarantees to system-level functions and modules.
The UniPro PHY adapter layer (Layer 1.5) serves to hide the differences between the different
MIPI PHY options (D-PHY or M-PHY). This layer allows configuration of various power states
and symbol encoding schemes.
The UniPro data link layer (Layer 2) de;nes 2 traTc classes: TC0 and TC1. TC1 data frames are
sent before TC0. A credit based Qow control mechanism enables receivers to tell the
transmitter how much buGer space is available and pause the transmission to avoid a receive
buGer overQow. An incorrect frame checksum at Layer 2 triggers an automatic retransmission.
A unique identi;cation number is assigned to each interface block on the Endo frame. The
interface block ID is assigned by ISO convention, starting from the rear of the Endo, from the
left and top, moving in the counterclockwise direction, and ending at the front of the Endo.
Since the interface block locations are the same regardless of rib placement, they can be
statically assigned. The result is shown in Figure 5.5.
Figure 5.5 - Interface Block Unique IDs
January 8, 2015
Page 68 of 107
The UniPro transport layer (Layer 4) handles connections between modules using logical data
streams. UniPro uses CPorts for communication between endpoints, which are roughly
analogous to sockets used in TCP or UDP. A pair of CPorts, one on each of two modules, can
form a bi-directional connection. Each module may have multiple CPorts, which enables a
module to simultaneously connect and communicate with multiple modules on an Ara device.
Project Ara is working with the MIPI UniPro standards committee to de;ne a standard
implementation of strong cryptographic protection for information transmitted over the UniPro
bus, which may be incorporated in a future MDK release as it becomes more mature.
5.2.2.2.
Layers 1.5-4 UniPro - Reference Implementation
A module can implement MIPI UniPro in multiple ways. One example is to use the Bridge
ASICs de;ned in the Network Stack Hardware section below. Module developer may also
instantiate UniPro with IP cores that are available from the UniPro known vendors section, or
develop an UniPro implementation directly from the MIPI speci;cations.
5.2.2.3.
Layers 1.5-4 UniPro - Known Vendor(s)
MIPI UniPro IP cores are available from vendors listed in Table 5.4.
Table 5.4 - MIPI UniPro Known Vendors
Vendor
Product
Synopsys
DesignWare MIPI UniPro Controller IP
Arasan
Arasan UniPro Controller IP
Cadence
Cadence IP Factory
HDL-IP
HIP 3600 UniPro IP Core
January 8, 2015
Page 69 of 107
5.2.2.4.
Layers 1.5-4 CSI-2 - Prototype Speci;cation
The prototype system uses Camera Serial Interface 2 (CSI-2) (V1.01 9-November-2010) to
interface between cameras and the AP. CSI-2 interfaces should be localized between
components on the module only. The interface between modules and the Endo uses M-PHY
and UniPro as de;ned in the previous sections.
5.2.2.5.
Layers 1.5-4 CSI-2 - Prototype Reference Implementation
CSI-2 speci;cations are implemented on the prototype Camera and AP modules with
Toshibas HS Bridge ASIC. The HS Bridge ASIC provides up to 2 links of CSI-2, and each link
supports 4 data lanes at 1 Gbps per data lane. CSI-2 data from a camera is translated into a
stream of UniPro packets in the HS Bridge on the Camera Module. The reverse translation is
performed on the HS Bridge attached to an AP on the AP Module. More detailed information
on HS Bridge is provided in the Network Hardware section and corresponding references.
5.2.2.6.
Layers 1.5-4 DSI - Prototype Speci;cation
The prototype system uses Display Serial Interface (DSI) (V1.1 22-November-2011) to
interface between displays and the AP. DSI interfaces should be localized between
5.2.2.7.
Layers 1.5-4 DSI - Prototype Reference Implementation
DSI speci;cations are implemented on the prototype Display and AP Modules with Toshibas
HS Bridge ASIC. The HS Bridge ASIC provides up to 2 links of DSI, and each link supports 4
data lanes at 1 Gbps per data lane. DSI data from a display is translated into a stream of
UniPro packets in the HS Bridge on the Display Module. The reverse translation is performed
on the HS Bridge attached to an AP on the AP Module. More detailed information on HS
Bridge is provided in the Network Hardware section and corresponding references.
5.2.2.8.
Layers 1.5-4 Bridged Interfaces
Modules on the prototype implement additional interfaces between module components and
the HS and GP Bridge ASICs. These interfaces include HSIC, I2C, I2S, SDIO, UART, GPIO,
and PWM, SPI. The sections below de;ne the speci;c standard and any deviations or
speci;c parameters implemented.
5.2.2.8.1.
HSIC Bridge - Prototype Speci;cation
The prototype system uses High-Speed Inter-Chip USB (HSIC) (V1.0 September-2007)
between the AP and the HS Bridge ASIC. HSIC interfaces should be localized between
5.2.2.8.2.
HSIC Bridge - Prototype Reference Implementation
HSIC speci;cations are implemented on the prototype modules with Toshibas HS and GP
Bridge ASICs. The HS Bridge ASIC implements an HSIC device, while the GP Bridge ASIC
implements an HSIC host. USB data is translated by the GP Bridge into UniPro packets and
routed through the UniPro switch in the Endo to other modules. More detailed information on
HS Bridge and GP Bridge is provided in the Network Hardware section and corresponding
references.
January 8, 2015
Page 70 of 107
5.2.2.8.3.
I2C Bridge - Prototype Speci;cation
The prototype system uses I2C (V2.1 January-2000) in several modules. I2C interfaces
should be localized between components on the module only. The interface between
modules and the Endo uses M-PHY and UniPro as de;ned in the previous sections.
5.2.2.8.4.
I2C Bridge - Prototype Reference Implementation
I2C speci;cations are implemented on the prototype modules with Toshibas HS and GP
Bridge ASICs. I2C data is translated into UniPro packets on Bridge ASICs and routed
through the UniPro switch to other modules. More detailed information on HS Bridge and GP
5.2.2.8.5.
I2S Bridge - Prototype Speci;cation
The prototype system uses I2S (5-June-1996) in the Receiver and AP Modules. I2S interfaces
5.2.2.8.6.
I2S Bridge - Prototype Reference Implementation
I2S speci;cations are implemented on the prototype modules with Toshibas HS and GP
Bridge ASICs. I2S data is translated into UniPro packets on Bridge ASICs and routed through
the UniPro switch to other modules. More detailed information on HS Bridge and GP Bridge
is provided in the Network Hardware section and corresponding references.
5.2.2.8.7.
SDIO Bridge - Prototype Speci;cation
The prototype system uses SDIO (V2.0 8-February-2007) in the WiFi module. SDIO interfaces
5.2.2.8.8.
SDIO Bridge - Prototype Reference Implementation
SDIO speci;cations are implemented on the prototype WiFi module with Toshibas GP Bridge
ASICs. SDIO data is translated into UniPro packets on Bridge ASICs and routed through the
UniPro switch to other modules. More detailed information on GP Bridge is provided in the
Network Hardware section and corresponding references.
5.2.2.8.9.
GPIO Bridge - Prototype Speci;cation
The prototype system uses GPIO in several modules. GPIO interfaces should be localized
uses M-PHY and UniPro as de;ned in the previous sections.
5.2.2.8.10.
GPIO Bridge - Prototype Reference Implementation
GPIO interfaces are implemented on the prototype modules with Toshibas HS and GP
Bridge ASICs. GPIO data is translated into UniPro packets on Bridge ASICs and routed
through the UniPro switch to other modules. More detailed information on HS Bridge and GP
5.2.2.8.11.
UART Bridge - Prototype Speci;cation
The prototype system uses UART in the WiFi module. UART interfaces should be localized
January 8, 2015
Page 71 of 107
5.2.2.8.12.
UART Bridge - Prototype Reference Implementation
UART interface are implemented on the prototype modules with Toshibas GP Bridge ASIC.
UART data is translated into UniPro packets on Bridge ASICs and routed through the UniPro
switch to other modules. More detailed information on HS Bridge and GP Bridge is provided
in the Network Hardware section and corresponding references.
5.2.2.8.13.
PWM Bridge - Prototype Speci;cation
The prototype system uses PWM in several modules. PWM interfaces should be localized
5.2.2.8.14.
PWM Bridge - Prototype Reference Implementation
PWM interface are implemented on the prototype modules with Toshibas HS and GP Bridge
ASICs. PWM data is translated into UniPro packets on Bridge ASICs and routed through the
UniPro switch to other modules. More detailed information on HS Bridge and GP Bridge is
provided in the Network Hardware section and corresponding references.
5.2.2.8.15.
SPI Bridge - Prototype Speci;cation
The prototype system uses SPI in several modules. SPI interfaces should be localized
5.2.2.8.16.
SPI Bridge - Prototype Reference Implementation
SPI interface are implemented on the prototype modules with Toshibas HS and GP Bridge
ASICs. SPI data is translated into UniPro packets on Bridge ASICs and routed through the
UniPro switch to other modules. More detailed information on HS Bridge and GP Bridge is
provided in the Network Hardware section and corresponding references.
January 8, 2015
Page 72 of 107
5.2.3. Layers 5+
5.2.3.1.
Layers 5+ - Greybus Speci;cation
The Ara network protocols at Layers 5 and above are de;ned within the Greybus Speci;cation,
also called Greybus. This document summarizes the main features of the Greybus
Speci;cation, and references the Greybus Speci;cation document provided in the reference
materials (Reference Materials\Documents\Greybus Speci;cation v0.1.pdf) whenever possible.
Figure 5.6 - Network Stack over Software and Hardware
Figure 5.6 shows the Greybus protocol for various classes of modules within the context of the
Ara network stack implementation in hardware and software. On the hardware end, modules
may have native a UniPro interface to the Endo. Example devices include cameras that utilize
MIPI CSI-3 for video streaming or mass storage devices that use UFS. New device class
protocols built on UniPro for audio streaming, wireless communications and others are also
under development. Devices without native UniPro will utilize a Bridge ASIC (HS or GP) to
communicate over the UniPro network. A Bridge converts common interfaces such as I2C,
USB, and UART for transmission over the UniPro network to an AP Module. Other Bridge
January 8, 2015
Page 73 of 107
ASICs in addition to the current Toshiba HS and GP Bridge ASICs are envisioned.
On the software side, there are 2 classes of modules: those conform to generic device classes
and all others. Both classes of modules are supported in software with the Greybus
speci;cation, which is implemented as part of a new Linux kernel subsystem. Greybus
performs communication between modules using Greybus Operations. A Greybus Operation
de;nes the semantics for a remote procedure call from one module to another. An Operation is
implemented by a pair of messages--one containing a request, and the other containing an
optional response. The Greybus subsystem implements device class protocols and Bridged
PHY protocols in terms of Greybus Operations. These operations are de;ned fully in the
Greybus Speci;cation document.
The Greybus subsystem, through the kernel and various subsystem interfaces, facilitates
interfaces to the Android platform and Android applications. The Greybus subsystem will
include a set of generic class drivers to support common devices such as batteries and human
interface devices. These class drivers will communicate with updated Android services and
HALs, modi;ed to enable support of unique Ara features such as hotplug and hardware
recon;guration.
Developers of non-class conforming modules may create a custom Android application and
utilize accessory-style APIs in the Android platform to interface with bridged PHY and other
non-device class APIs within the Greybus subsystem to access data from their module.
January 8, 2015
Page 74 of 107
5.2.3.2.
Layers 5+ - Greybus Prototype Reference Implementation
Figure 5.7 shows the Greybus protocol in the prototype system. The Greybus protocol and
software implementation will be continuously developed and updated with new features over
the course of the Ara prototype development period, culminating with the features described
in the objective system.
As of the current MDK release, generic class drivers for batteries and vibrators have been
speci;ed in the Greybus speci;cation, but have not been fully implemented in software. In
lieu of generic class drivers, existing prototype modules use device-speci;c drivers and
HALs. HS Bridge ASICs in the Camera, Display, and AP Modules tunnel CSI-2 and DSI data
transparently over the UniPro network.
All other Prototype Modules utilize a GP Bridge and bridged PHY drivers in the Greybus
subsystem. As of the current MDK release, the Greybus Speci;cation and Greybus
subsystem implementation support I2C, GPIO, UART, and PWM protocols. Refer to the
Greybus Speci;cation document for details on Greybus Operations and data formats. A
summary of the Greybus subsystem is given in the Software section.
Figure 5.7 - Prototype Network Stack over Software and Hardware

January 8, 2015
Page 75 of 107
5.2.4. Network Stack Hardware - Known Vendor(s)

Peripherals can interface with the Ara network either through a native UniPro/M-PHY protocol
implementation or by utilizing a Bridge ASIC. Two such UniPro bridge ASICs are under
development by Toshiba Semiconductor and Storage Products Company: a UniPro HighSpeed (HS) Bridge and a UniPro General Purpose (GP) Bridge. Table 5.5 provides some highlevel speci;cations for the two Bridge ASICs. More detailed information including data sheets
are available from Toshiba.
Table 5.5 - Toshiba UniPro Bridge ASIC Speci$cations
ASIC
UniPro Interfaces
Peripheral Interfaces
Chip Information
HS Bridge
2-lane bi-directional MMPORTs

MIPI M-PHY v3.0 Type-1 with
maximum speed at HS-G3b
mode (5.8 Gbps/lane, 11.6
Gbps/M-PORT)
2 MIPI CSI-2 links (4 D-PHY lanes

@ 1Gbps/lane)
2 MIPI DSI links (4 D-PHY @
1Gbps/lane)
USB HSIC v1.0 host
I2C Master with normal, fast, and
fast mode plus
I2S audio with max 48 kHz stereo
10+ GPIO lines (shared)
Power: <1170 mW
@ max voltage
Size: 5 mm x 5 mm
Rated 85
Ambient
Pin-count: 107
Part No:
T6WR5XBG
GP Bridge
2-lane bi-directional MMPORTs

MIPI M-PHY v3.0 Type-1 with
maximum speed at HS-G3b
mode (5.8 Gbps/lane, 11.6
Gbps/M-PORT)
USB HSIC v1.0 host

SDIO v2 host controller
SPI Master
I2C Master with normal, fast, and
fast mode plus
I2S audio with max 48 kHz stereo
2 UARTs
10+ GPIO lines (shared)
Power: <890 mW @
max voltage
Size: 5 mm x 5 mm
Rated 85
Ambient
Pin-count: 107
Part No:
T6WR6XBG
5.2.5. Network Stack Prototype Hardware - Known Vendor(s)

The prototype system uses both HS and GP Bridges. The Prototype AP, Camera, and Display
Modules use an HS Bridge and the Prototype Receiver, WiFi, 3G Cellular, Battery, USB,
Speaker, and Pollution Sensor Modules use a GP Bridge. Schematics for each prototype
module are provided in the reference materials.
The Toshiba Bridge ASICs executes custom ;rmware that implements the Greybus
speci;cations. The current ;rmware is based on the NuttX open-source real-time operating
system (RTOS). The source tree for the ;rmware including the RTOS and Greybus-speci;c
implementations will be available from the Project Ara website.
January 8, 2015
Page 76 of 107
6.
Software Stack
Figure 6.1 shows an abstracted view of the Ara software stack. The Ara software stack
currently requires that exactly one Application Processor (AP) Module running Android is
present in the system. (Support for multiple AP modules may be included in a future release of
the MDK.) From the perspective of the software, there are two types of modules: those which
conform to a particular device class and Android HAL/subsystem (such as cameras, displays,
human interface devices, etc.), and those which dont conform to any device class (modules
with functions which are novel, unique, or otherwise special-purpose). The latter case often
have associated custom libraries and/or applications.
Figure 6.1 - Software Stack
Figure 6.1 shows the software interfaces and interactions for conforming and non-class
conforming modules. Conforming modules use generic device class drivers that interface with
updated Android HALs and services to enable the unique modular features on the Ara platform.
These features include support for hotplugging modules and recon;guring the device without
having to recompile and update the kernel and Android con;guration. A set of device class
de;nitions, UniPro-based communication protocols, and associated kernel drivers will enable a
set of devices commonly found on smartphones today including displays, cameras, batteries,
sensors, audio devices, etc.
Developers of non-class conforming modules can create a custom Android Application, which
can then access Android bus interface APIs to communicate with the Bridge PHY Protocol
Drivers in the Greybus subsystem to connect to and manage the module.
January 8, 2015
Page 77 of 107
Communication between modules in the Ara phone is abstracted in the form of Greybus
Operations. Both device class protocols and Bridge PHY protocols are encapsulated as
Greybus Operations and are detailed in the Greybus Speci;cation provided in the reference
materials.
The present prototype platform software is a modi;ed version of the Linaro Android L
release, targeting Marvell AP and NVidia APs. The source tree for each AP will be available
made available along with developer hardware, to be announced on the Project Ara website.
Some AP-speci;c binaries have proprietary licenses and may require additional end-user
license agreements.
Figure 6.2 - Prototype Software Stack
Figure 6.2 shows an overview of the software interfaces for the prototype platform. All
prototype modules contain either a HS or GP Bridge ASIC. The Prototype Camera, Display,
and AP Modules use an HS Bridge ASIC, which tunnels CSI-2 and DSI traTc over the UniPro
network transparently. While generic class drivers for displays, cameras, and other common
devices are still in development, the Prototype Camera and Display Modules use devicespeci;c drivers and HALs targeted for each AP.
Other prototype modules (e.g. Battery, Receiver, Speaker, WiFi/BT, 3G Cellular Modules) use
a GP Bridge ASIC and utilize one or more bridged PHY protocols. The HS Bridge ASIC also
implements some bridged PHY protocols, which are accessed the same way via Greybus
Operations. The Bridged PHY Protocol Drivers in the Greybus subsystem implement their
respective protocols Operations and interface with existing kernel APIs to enable end-to-end
communication between Android applications and module devices.
January 8, 2015
Page 78 of 107
6.1.
Kernel
Linux device drivers provide low-level hardware support on Android devices. On a standard
smartphone, the available hardware is ;xed, allowing device manufacturers to pre-select a set
of device drivers. On an Ara phone, however, almost all of the hardware which is normally an
immutable part of a smartphones design is designed to be user replaceable and hotpluggable.
6.1.1. Kernel - Speci$cation

The primary requirement to enable Ara features in the kernel is the implementation of the
Greybus speci;cation, which de;nes how modules communicate over the UniPro network on
an Ara device. The Greybus speci;cation also de;nes messaging needed to complete systemlevel functions (de;ned in a later section) such as module manifest declaration, EPM control,
and RF bus con;guration. The Greybus speci;cation is detailed in a separate document
provided with the reference materials (Reference Materials\Documents\Greybus Speci;cation
v0.1.pdf).
6.1.2. Kernel - Reference Implementation

Figure 6.3 depicts an abstracted view of a reference implementation of the Greybus
speci;cation as a kernel subsystem and its interfaces to other kernel components. The
Greybus kernel reference implementation is available as a kernel module, which can compiled
against a source tree targeted for various APs. The Greybus kernel module is hosted on Github
and will be continuously updated as part of the Ara platform development activities. This kernel
code will be merged into the main Linux kernel releases on kernel.org when the implementation
is completed.
January 8, 2015
Page 79 of 107
Figure 6.3 - Kernel Subsystem Interfaces
As shown in Figure 6.3, the Greybus kernel module is designed around a central Greybus Core.
The key functions of the Greybus Core include interfacing with the virtual ;le system, parsing
module manifest information to identify modules and their capabilities, handling power
management features, controlling EPMs to lock and release modules, and con;guring the RF
bus in the Endo to route RF signals between modules. The Greybus core coordinates these
functions with the supervisory controller (SVC) in the Endo. These system-level functions,
which require interfaces between the SVC, AP, modules, and users are de;ned in a later
section.
The main function of the Greybus subsystem is to perform the duties of a kernel driver for each
module. On a traditional smartphone, the kernel can be compiled with a set of custom drivers
since all the devices are known. To enable a seamless experience where users may swap
modules from diGerent vendors, with diGerent device classes and diGerent features, and do it
with nominal technical skills required of any smartphone user, the traditional kernel driver
model must be adapted with a more Qexible approach.
To enable the goals of the Ara modular platform, a set of generic class drivers will be speci;ed
in the Greybus speci;cation and implemented in the Greybus subsystem. The set of generic
class drivers will span a broad range of module devices typically found on smartphones. The
current plan includes the the following device classes: audio, batteries and chargers, Bluetooth
devices, cameras, consumer IR devices, displays, GPS, input devices, lights, NFC, sensors,
January 8, 2015
Page 80 of 107
vibrators, WiFi, baseband, and other network devices, and storage devices. Future versions of
the MDK and Greybus speci;cation will include details for each device class.
As of the current MDK release, the Greybus speci;cation document includes de;nitions of two
generic device classes: batteries and vibrators. These relatively simple devices were chosen to
serve as a path;nder for more challenging devices. Even among devices that perform the same
function (i.e. cameras, WiFi), their drivers can be extremely varied among manufacturers and
product lines. To ensure that the Ara platform can accommodate the broadest set of devices,
generic class drivers must be developed carefully to ensure broad application without
sacri;cing signi;cant performance. Similarly, we are seeking feedback from the developer
community including device manufacturers and device driver vendors to help us compose the
appropriate device class de;nitions in the Greybus speci;cations. Please contact us at aradev@google.com if you are interested in engaging in these activities.
One of the advantages of the Ara platform is the ability to accommodate non-traditional
devices in a smartphone. Modules that do not fall within a generic class and thus unable to use
the generic class drivers are supported through a Bridge ASIC and the Bridge ASIC Driver in
the Greybus subsystem. Bridge ASICs are used to translate between UniPro and various
common interfaces including I2C, I2S, and USB. The Network section details the complete list
of Bridged interfaces supported by the current Bridge ASICs. The Greybus speci;cation
de;nes the operations used on a connection implementing these Bridge PHY protocols, and
the Bridge ASIC Driver allows developers to access and manage these connections with an
Android Application through Android APIs and standard kernel subsystem interfaces.
As shown in Figures 5.5, AP Modules with a native UniPro host controller are expected and will
be supported by the Greybus subsystem with a corresponding UniPro host controller driver.
The UniPro host controller will likely be tightly integrated with the AP and result in custom
drivers compiled for each AP.
In the near term and beyond, AP Modules without a native UniPro interface will be supported
through an HS Bridge ASIC. The Greybus subsystem includes an HS Bridge host controller
driver to communicate with and manage the HS Bridge ASIC. As shown in Figure 5.6, the
current HS Bridge ASIC is exposed to the AP through an HSIC USB interfaces. The Greybus
subsystem provides an interface between the HS Bridge host controller driver and the kernel
USB subsystem.
Finally, Figure 6.3 shows the interfaces between the Greybus subsystem and various kernel
subsystems. The generic class drivers and the Bridge ASIC Driver interface with one or more
corresponding kernel subsystems. For example, the I2C Bridged PHY protocol driver in the
Bridge ASIC Driver interfaces with the kernel I2C subsystem. These interfaces provide a
convenient abstraction to support platform-speci;c connections, but also serve to limit
January 8, 2015
Page 81 of 107
userspace access to the kernel with the goal of minimizing system crashes and security
breaches.
6.1.3. Kernel - Prototype Reference Implementation

The prototype Android release includes a kernel tree in kernel/linaro/ relative to the Android
source checkout directory. The kernel is based on version 3.10 and includes vendor-speci;c
display and camera drivers for prototype modules listed in the Mechanical and Layout
section.
The other major component in the kernel, as shown in Figure 6.4 is the Greybus subsystem,
which can be obtained from Github and compiled against a source tree targeted for the
Prototype Marvell and NVidia APs. They Greybus subsystem reference implementation will
be continuously updated with the goal of supporting the full set of class drivers and Bridged
PHY protocols shown in Figure 6.3.
As of the current MDK release, the Greybus subsystem implements generic class drivers for
batteries and vibrators and supports the following Bridge PHY protocols: I2C, PWM, UART,
and GPIO. Since the current Marvell and NVidia APs are implemented with HS Bridge ASICs,
the current prototype Greybus subsystem only includes the HS Bridge ASIC host controller,
accessed through the Bridge ASICs HSIC interface and the APs USB subsystem as
previously de;ned.
Figure 6.4 - Prototype Greybus Subsystem Reference Implementation

January 8, 2015
Page 82 of 107
6.2.
Android
The Android software stack is shown in Figure 6.5 highlighted with modi;cations and additional
components that will be developed to support the unique features of the Ara platform. Android
Applications are shown at the very top of stack. The Android Settings App will be modi;ed to
allow hardware con;gurations to change dynamically (e.g. enable/disable location services
when GPS module is removed). An Ara Manager App will also be introduced to facilitate user
interactions with modules on the device. The Ara Manager App will allow users to get detailed
information on all the modules currently attached to their device and swap them by
commanding the EPM(s) in the Endo to release. The Ara Manager App and required module
interfaces will be provided in a future MDK release.
Android System Services are application components that perform long-running operations in
the background and does not provide a user interface. As shown in Figure 6.5, many of these
services will be modi;ed to enable Android to support hotplug and hardware recon;guration
features. In addition, a new Endo service will be developed to support Android Applications
that make use of Ara features. Among its responsibilities, the Endo Service will
register/unregister the Ara Manager App, provide hotplug noti;cation and Endo information (i.e.
geometry, orientation) to various module developer-supplied Applications, support EPM
control, and control module power modes.
Figure 6.5 - Ara Android Stack

January 8, 2015
Page 83 of 107
Finally, Android Hardware Abstraction Libraries (HAL) are implemented as shared libraries; their
code runs within Androids system services. Unlike device drivers, HAL APIs are speci;ed by
Google and are updated with each release. Device manufacturers provide library binaries which
implement these interfaces in their devices system images. These libraries are then
subsequently loaded by the relevant system services as part of their initialization. Among other
things, HALs provide an abstraction barrier between Android system services and the various
device driver interfaces exposed by the kernel for diGerent hardware peripherals those services
must control.
Current HAL APIs assume a ;xed hardware con;guration and will require modi;cations to
support hot-plugging features inherent to the Ara architecture. Firstly, a set of HALs will be
modi;ed, as shown in Figure 6.5 to match the set of kernel device class drivers. These HALs
will be adapted to support hotplugging events. Each HAL will monitor device availability and
return generic values to dependent services without causing the system to crash in the event
that a device is not present (e.g., provide null or zero values if GPS sensor is not present or
issue off commands for user-controllable devices like WiFi). HALs will also detect any change in
module availability and notify dependent services upon module insertion and device availability.
A future MDK release will address these modi;cations in more detail.
6.2.1. Android HALs - Speci$cation

We are currently developing a modi;ed version of Android L to enable dynamic hardware
con;gurations on the Ara platform. These modi;cations will include support for modules to be
swapped and hotplugged, support for Greybus, and integration with Google Play services for
dynamic driver and application distribution. The plan is to merge these modi;cations back into
mainline Android in the future. Speci;cations for Android HAL will be de;ned in full in a future
MDK release.
January 8, 2015
Page 84 of 107
6.2.1. Android HALs - Prototype Reference Implementation

The prototype Android release includes existing HALs, yet to be modi;ed to support
hotplugging and dynamic hardware recon;guration. Additionally, the prototype Display and
Camera Modules also require device-speci;c HALs targeted for each AP.
As shown in Figure 6.5, a representative set of HALs will be modi;ed to support required Ara
features. Modi;cations for each existing HAL will vary in complexity and scope. The
Bluetooth HAL for example can be extended by ensuring a maximum set of Bluetooth
pro;les and con;gurations can be accommodated. On the other hand, the Battery HAL must
be modi;ed to support a wide range of battery technologies, multiple battery modules, and
enable hotplugging and related functions such as aggregation and calculation of overall
system battery usage and statistics. All modi;ed HALs and a description of the required
modi;cations will be provided in a future MDK releases.
6.2.2. Android Application - Speci$cation

In general, Android applications for the Ara platform are not in any signi;cant respect diGerent
than traditional Android apps. Consequently, Ara devices are anticipated to be compatible with
most standard apps. Where unique Ara features are required, the Endo Service will provide
noti;cation and callback interfaces to Android applications. These interfaces will be speci;ed in
a future MDK release.
The Android developers portal describes Android application development. Additional
guidance and reference materials are also readily available from many third party sources. App
developers are encouraged to pay attention to application stability and graceful behavior in
light of dynamically varying availability of hardware resources (as with hot-plug, for instance).
6.2.3. Android Application - Reference Implementation

The Android source tree includes several pre-built applications available under
packages/apps/, relative to the Android source checkouts root directory. Some example Ara
Android Applications will be provided in a future release.
6.2.4. Android Application - Prototype Reference Implementation

As shown in Figure 6.5, the Android Settings App will be modi;ed with Ara-speci;c features,
and a new Ara Manager App will be developed to facilitate user-management of modules on
the device. These Applications are currently under development and will be provided in a
future MDK release.
January 8, 2015
Page 85 of 107
6.3.
Prototype Development Use cases
This section describes several use cases module developers may encounter and includes
references to existing support infrastructure provided by the prototype software platform.
6.3.1. CSI-2/DSI Devices

Cameras and display modules with D-PHY based interfaces (CSI-2/DSI) and developed for
the current prototype platform should utilize an HS Bridge ASIC or implement an equivalent
bridged interface to the UniPro network. The HS Bridge ASIC tunnels CSI-2 and DSI over the
UniPro network and delivers the data to an AP Module on the device. AP-speci;c kernel
drivers and HALs can be implemented as with the current prototype reference
implementation.
6.3.2. I2C, UART, GPIO, PWM Devices

The HS and GP Bridge provide I2C, UART, GPIO, and PWM interfaces to module
components. Communication with these interfaces are supported through the Greybus
subsystem. Developers should reference the Greybus speci;cation for speci;c operations
used to connect and manage a device through the Greybus subsystem. Developers should
use existing HALs and Android services until modi;ed version are available.
6.3.3. USB, SDIO, I2S Devices

The HS Bridge provides USB and I2S interfaces to module components, while the GP Bridge
provides USB, I2S, and SDIO interfaces to module components. Communication with USB,
SDIO, and I2S interfaces will be supported through Greybus although these interfaces are
not yet implemented in the Greybus subsystem. Developers should use existing HALs and
Android services until these features are added to the Greybus.
January 8, 2015
Page 86 of 107
7.
System-Level Functions
The following sections illustrate system-level functions performed by Ara modules. Modules
will utilize the network and software stacks (the kernel Greybus subsystem and Android Endo
Service in particular) to exercise these functions. Modules interface with the supervisory
controller in the Endo and/or the AP Module to carry out these functions. Developers should
refer to the Greybus Application Protocol document and other reference materials for details.
The subsequent subsection provide an overview of these functions.
7.1.
Module Wake/Detect
The Endo expects Wake and Detect signals for each module. Wake signals are used to bring
the phone out of a low-power standby state. A Wake signal is sent from a module to the
supervisory controller when a power button is pressed. This brings the supervisory controller
out of standby state, and the supervisory controller, in turn, sends Wake signals to each of the
installed modules to turn them on.
Detect signals allow the Endo to detect when modules are inserted and removed. Detect
signals are used to communicate to a module and the Endo when a module is inserted or
removed. Power consuming modules naturally lose power when removed from the Endo, so
they automatically shut oG. Modules with batteries must place themselves in a powered-down
standby state when they lose the detect signal from the Endo.
7.1.1. Module Wake/Detect Electrical - Specification

Each modules Wake and Detect signals are multiplexed on a single pin (wake-detect pin),
which is part of the interface block connecting each module to the Endo. The wake-detect pin
is on the module connector and allows the Endo to determine if a module is present, the
module to determine if an Endo is present, the Endo to wake the module from sleep, and the
module to wake the Endo from sleep.
The Endo pulls each wake-detect pin up to 1.8 V by default. A module should pull its wakedetect pin down to 0 V by default when the module is not in the Endo. The Endo and module
must each connect the wake-detect pin to ground with a 10 M resistor.
When a module is inserted into the Endo, the voltage on the wake-detect pin will float to 0.9 V.
Modules should use this transition to signal a module insertion event. The supervisory controller
in the Endo similarly uses this transition (from 1.8 to 0.9 V) to determine when and where a
module is inserted in the Endo.
To wake the supervisory controller on the Endo, a module should pulse the wake-detect pin
temporarily low (< 0.64 V), then returning to 0.9 V. Similarly, the module should wake from
standby (if implemented) when it detects the wake-detect pin is pulsed high (>1.285 V) by the
January 8, 2015
Page 87 of 107
Endo. The module must not load the wake-detect pin with more than 5 nA of input bias current
to read the state of the pin.
7.1.2. Module Wake/Detect Electrical - Prototype Reference Implementation

Figure 7.1 shows a wake/detect reference implementation in the prototype modules. The
module wake-detect pin on the interface block is connected to ground with a 1 M resistor.
Two analog comparators connect to the AP or GP Bridge ASIC to signal module detect and
wake events. The reference voltages for the comparators are exactly in between the 3
voltage levels in the speci;cations.
The WAKE_OUT pin is normally held at High-Z (>>1 M). To send a wake signal to the Endo,
the Bridge ASIC pulls the voltage to 0 V. The EDA ;les and schematics in the module
templates details pinouts for the circuit shown in Figure 7.1.
Figure 7.1 - Prototype Reference Implementation of Wake/Detect Circuit
7.2.
Module Initialization/Hotplug Event
After a module is inserted into an Endo (or when a device is powered on with the module in the
Endo), an initialization process is required to establish a link to the UniPro network, exchange
module information, attach EPM(s), and start communication with software and other modules
on the device.
Figure 7.2 de;nes a high-level sequence of events during the module initialization process. The
sequence begins when a module is detected on the Endo. The SVC in the Endo noti;es the AP
Module on the device and setups a UniPro connection. The module must subsequently report
January 8, 2015
Page 88 of 107
its module manifest (de;ned in the subsequent section), which is veri;ed by the AP.
Subsequently, the module is able to communicate on the UniPro network through the switch in
the Endo. A much more detailed sequence diagram will be provided in a future MDK release to
address speci;c messaging required by modules.
Figure 7.2 - Module Initialization Process Sequence Diagram
7.2.1. Module Information - Speci$cation

Modules must contain self-descriptive information in order to identify itself to the UniPro
network. This information is found in the module manifest, which describes components present
within the module that are accessible via UniPro. The module manifest includes a set of
descriptors which present a functional description of the module. Together these define what the
module is from an application protocol layer, including its capabilities, and how it should be
communicated with. For example, a Display Module will provide its vendor/manufacturer name,
device class indicating the type of device driver it needs, screen resolution, and other
performance identi;ers needed to operate the module. The Greybus speci;cation document
provides the required ;elds, descriptors, and data formats for the module manifest.
7.2.2. Module Information - Prototype Reference Implementation

A module manifest generator tools that generates compliant module manifest data from an
input ;le is provided on GitHub. The tool will be maintained and updated along with the
Greybus speci;cation.
7.3.
Active Thermal Management
Active thermal management features protect the user and the phone from excessive heat
buildup. Excessive heat generated from a module can cause injury to user and cause
neighboring modules to fail. Temperature sensors in the Endo and the modules provide
January 8, 2015
Page 89 of 107
measurements to the supervisory controller. If temperatures exceed prede;ned limits, modules

may receive warnings, and in the worst case, power will be removed.
Active thermal management is not implemented in the prototype platform.
7.4.
Power Management
As with a traditional smartphone, an Ara device must be able to conserve power when not in
active use. Traditionally, the AP and power manager software will place various devices into
standby mode. On an Ara device, modules must similarly be commanded to enter a powerconserving mode. When the user is ready to use the device, modules will be awaken through
the wake/detect signal.
In addition, modules must declare their expected power usage in various scenarios (active,
standby, etc.) and stay within those limits. The power manager uses this information to predict
remaining battery capacity and notify the user when insuTcient power is available.
Most power management features are not implemented in the prototype platform.
January 8, 2015
Page 90 of 107
8.
Module Compliance
This section provides compliance speci;cations for Ara modules needed to demonstrate their
conformance with the MDK. Environmental compliance speci;cations are designed to ensure
modules can survive typical usage scenarios and environments in a broad range of
geographies. Whenever possible, these speci;cations are written in terms of survivable limits
only. It is up to module developers to infer an appropriate quali;cation procedure that
comports with good engineering practice and their own quality assurance methodology. The
accompanying reference implementation sections provide test procedures, con;gurations, and
other relevant information to demonstrate compliance to the speci;cation.
This section also de;nes other procedures needed to demonstrate compliance with the MDK.
These procedure ensure modules meet the geometric, material, power, electrical, software, and
other speci;cations de;ned in previous sections of the MDK.
8.1.
Environmental Compliance
8.1.1. Thermal Loads

It is critically important to restrict thermal loads from modules in the Ara architecture because
of their eGects on neighboring modules and the user. Since modules are nominally sealed from
the environment, thermal loads generated are conducted either down into the Endo frame and
to the other modules or up into the module shell and to the user.
8.1.1.1.
Thermal Loads - Speci;cation
The Ara architecture has a thermal monitoring and management system. Modules must
monitor their temperatures and adhere to temperature limits. Modules must provide
measurements to the supervisory controller. When temperatures exceed prede;ned limits,
modules may receive warnings, and in the worst case, the supervisory controller will cut power
to the module.
8.1.1.2.
Thermal Loads - Prototype Speci;cation
Prototype modules should limit their maximum power output such that the energy transferred
to the module base and module shell does not exceed 25 above room temperature.
Developers may use a value of 25 room temperature for their analysis.
8.1.1.3.
Thermal Loads - Prototype Reference Implementation
Tests to verify conformance to the speci;cations have not been implemented for the
prototype. Details of compliance test procedures will be provided in a future MDK release.
January 8, 2015
Page 91 of 107
8.1.2. Ambient Temperature and Humidity

8.1.2.1.
Ambient Temperature and Humidity - Speci;cation
Relative humidity (RH) is the the ratio of the actual vapor pressure of the air to the saturation
vapor pressure and indicates the degree of saturation of the air. Modules are likely to be stored
or operated in environments with varying ambient temperatures and relative humidity. Warm
and humid conditions can occur year-round in tropical areas and seasonally in mid-latitude
areas, subjecting modules to combinations of changes in temperature, and relative humidity.
Modules must also operate through frequent and rapid extreme temperature and humidity
changes such as when transitioning from a humid and hot tropical environment into an airconditioned environment.
Tests should be conducted in environments with 1) constant high temperature and humidity
and 2) variations in temperature and humidity levels, as de;ned below:
1. Constant high humidity environment: This condition is characterized by relative
humidity above 95 percent in association with nearly constant 80 F (27 C) temperature
occurring for cycle periods of at least one day. This test should be cycled at least 15
times.
2. Variable temperature and humidity levels: Cycles in this test environment require the
module to remain for one hour in an an outdoor high temperature and RH environment
at temperatures between 86 F to 104 F (30 C to 40 C) and RH of at least 90%
followed by an immediate transition to an indoor climate controlled environment with
temperatures between 70 F to 80 F (21 C to 27 C) and RH of 30% to 60% for one
hour. This test should be cycled at least 100 times.
These tests should not aGect the material or normal operation of the module and its
components. A visual inspection of the module should be performed after each cycle to verify
that there are no visible surface eGects including oxidation and/or galvanic corrosion or
chemical or electrochemical breakdown of surface coatings. There should be no visible
swelling of materials and no changes in elasticity or plasticity of the outer surfaces.
Functional tests should be performed after each cycle to ensure module operation remains
unaGected.
8.1.2.2.
Ambient Temperature and Humidity - Prototype Reference Implementation
Place the module inserted into an Endo in an environmental test chamber as speci;ed in Test
1 for at least 15 cycles and Test 2 for at least 100 cycles. The device should be on during the
tests. Observe the eGects on the module throughout the duration of the test. Visually inspect
the module after each cycle per the speci;cation and perform a functional test of the module
to ensure module operation remains unaGected.
January 8, 2015
Page 92 of 107
8.1.3. Electrostatic Discharge (ESD)

8.1.3.1.
ESD - Speci;cation
Electrostatic discharge results from conditions that allow the buildup of electrical charge from
contact or separation of charge from two non-conductive materials. When the charged object
is brought in proximity of another object at lower potential, energy is released in the form of
ESD. Since the human body is one of the most common generators of ESD, the IEC 61000-4-2
standard de;nes test speci;cations that simulate a typical ESD event from the human body in
the context of mobile phones, laptops, computers and other electronic devices. Discharge into
equipment may be through direct contact (contact discharge method) or just prior to contact
(air discharge method).
Room temperature in the test environment must be between 15 and 35 and relative
humidity must be between 30 and 60%. In the case of contact discharge, modules must
function normally with +/- 6 kV ESD and sustain no damage with +/- 8kV ESD at all sensitive
locations such as the interface blocks and module base/shell interfaces. In the case of air
discharge, modules must function normally with +/- 10 kV ESD and sustain no damage with +/15kV ESD. Speci;c test points for each module type will be provided in a future MDK release.
8.1.3.2.
ESD - Prototype Reference Implementation
Use an IEC-standard-compliant ESD generator and apply discharges with the module by
itself at locations and discharge voltages provided in the speci;cations. Insert the module
into an Endo and perform a functional test to ensure module operation remains unaGected.
Repeat the procedure with the module in the Endo powered on at accessible locations
provided in the speci;cations.
8.1.4. Shock
8.1.4.1.
Shock - Speci;cation
Shock tests are performed to provide a degree of con;dence that modules can physically and
functionally withstand the relatively infrequent, non-repetitive shocks encountered in handling,
transportation, and operational environments. These tests also help to determine the fragility of
the module and facilitate the design of packaging that provides adequate protection for the
module.
Module developers should drop the module from a height of 48 (4) on each face, edge and
corner for a total of 26 drops onto a hard surface. Orient the module so that, upon impact, a
line from the struck corner or edge to the center of gravity of the case and contents is
perpendicular to the impact surface.
January 8, 2015
Page 93 of 107
Module developers should also repeat each drop test with the module in an endo with a
representative set of modules.
Subsequent to each drop, developers should check the module visually and/or operationally
during the drop-test to simplify any follow-on evaluation that may be required. Note the impact
point or surface for each drop and any obvious functional degradation or physical damage.
Drop-tests should not aGect the physical or functional integrity of the module, its components,
or the phone.
8.1.4.2.
Shock - Prototype Reference Implementation
Perform drops from a quick-release hook or pneumatic drop tester. For the Qoor or barrier
receiving the impact, use two-inch plywood backed by concrete. Visually inspect the module
and/or module with Endo after each drop and verify structural integrity and operation per the
speci;cations.
8.1.5. Vibration
8.1.5.1.
Vibration - Speci;cation
Ara modules, like all portable consumer electronics, need to meet industry standards for
reliability with respect to vibration and fatigue testing. Vibration tests evaluate the functional
and structural integrity of a module subjected to representative vibration during assembly,
packaging, transportation handling, and everyday operation.
Modules should be subject to 5 minutes of shaking in each orthogonal axis, in each direction at
30 Hz and a displacement of 0.06 in. Check the module visually and/or operationally during the
test to simplify any follow-on evaluation that may be required. Modules should not show any
obvious functional degradation or physical damage during and after each test. Vibration can
also cause damage or dislodge electronic circuits or connectors resulting in malfunction or
defective operation. Perform a functional test after each test to verify module operation
remains unaGected. Perform the tests for the module individually and with the module in the
Endo.
January 8, 2015
Page 94 of 107
8.1.5.2.
Vibration - Prototype Reference Implementation
Secure the module to the shaker table and induce vibrations as speci;ed in the
speci;cations. Repeat the test for each orthogonal axis and with the module by itself and
with the module in the Endo while powered on.
After each test, visually inspect the module to ensure there are no visible eGects of vibration
including mechanical deformation of the module as a result of stress on structural elements.
Perform a functional test to verify module operations after each test.
8.2.
Mechanical Compliance
8.2.1. Mechanical Fit

8.2.1.1.
Mechanical Fit - Speci;cations
Modules must be able to ;t into any compatible Endo and operate reliably. Modules must be
manufactured to the mechanical tolerances speci;ed in the Mechanical section and associated
CAD models and drawings in the reference materials.
8.2.1.2.
Mechanical Fit - Prototype Reference Implementation
A high-precision optical measurement tool should be used to measure mechanical tolerances
for manufactured modules. Tolerances should be compared against the speci;cations in the
Mechanical section and associated CAD drawings and veri;ed for compliance.
8.2.2. EPM Hold

8.2.2.1.
EPM Hold - Speci;cations
The EPMs in the Endo must interface with modules to ensure suTcient force is applied in the
attach and detach states. Modules must conform to the material and geometric speci;cations
(including applicable tolerances) in the Mechanical section and associated CAD models and
drawings in the reference materials to ensure compliance. Front module attachment spring
should have a spring force constant in the order of 1 N/mm per speci;cations provided in the
Mechanical section.
January 8, 2015
Page 95 of 107
8.2.2.2.
EPM Hold - Prototype Speci;cations
The current prototype EPMs should provide a maximum holding force in tandem with the
module Hiperco 50 inserts of 15 N each. 2x2 modules attach to 2 EPMs for a maximum
holding force of 30 N. Depending on the insertion direction, 1x2 modules may attach to either
1 or 2 EPMs.
8.2.2.3.
EPM Hold - Prototype Reference Implementation
An electromechanical pull tester should be used to test EPM hold. The pull tester should
apply forces in increments of 1 N along each applicable axis until the module releases. The
test should be performed for EPMs in the attach and release states. Modules should remain
attached for pulling forces up to the maximum required EPM hold force of 15 N and 3 N per
interface block in the attach and detach states respectively.
Front modules should be subjected to EPM attach and release in the Endo. A visual
inspection should be performed to verify the spring loaded Hiperco-50 insert on the module
is locked into the Endo in the attach state and Qush with the module in release state.
8.3.
Power Compliance
8.3.1. Voltage Sweep

8.3.1.1.
Voltage Sweep - Speci;cations
The Power section de;nes a common voltage bus on the Endo and speci;es its operating
range between 3.3 and 4.8 V. The voltage is equal to that of the power provider or storage
module with the highest voltage on the bus. As the voltage of the shared bus is variable, all
modules must be fully functional across the entire speci;ed voltage range.
8.3.1.2.
Power Sweep - Prototype Reference Implementation
The voltage level on the common voltage bus should be varied from 3.3 V to 4.8 V in steps of
0.3 V using an adjustable benchtop power supply. Perform a functional test to verify module
operations after each voltage step change.
8.3.2. Power Input/Output Noise

8.3.2.1.
Power Input/Output Noise - Speci;cations
Modules should limit voltage and current spikes that create noise on the shared power bus.
Modules should also use suTcient power line conditioning to tolerate some noise on the
shared power bus.
January 8, 2015
Page 96 of 107
Modules should limit electromagnetic interference (EMI) generation so it is not coupled to other
modules through conduction on the power and data lines or through radiation. Modules
should also tolerate some EMI introduced by other modules installed in the Endo.
Additional speci;cations for power line noise and EMI compliance will be provided in a future
MDK release.
8.3.2.2.
Power Input/Output Noise - Prototype Reference Implementation
Details of compliance test procedures will be provided in a future MDK release.
8.3.3. Power Draw and Discharge

8.3.3.1.
Power Draw and Discharge - Speci;cations
The power budget of an Ara device is determined by the aggregation of power consumers,
chargers, and power storage devices on the device. Furthermore, the power budget can
change anytime a user removes or adds a module, even while the device is powered on. The
power manager in the Endo is responsible for maintaining the overall power budget of the
device, and it must be able to determine and predict the power draw and discharge rates from
each module to ensure suTcient power is available or initiate power-preserving measures
otherwise. Thus, power consumer modules must declare their expected power draw and
ensure they do not exceed these limits. Similarly, chargers and power storage modules must
declare their expected discharge rates and ensure these discharge rates can be achieved
during operation.
8.3.3.2.
Power Draw - Prototype Reference Implementation
Power consuming modules should be placed in all relevant power modes and operating
conditions. The power draw should be measured and compared against declared power
draw budgets.
Chargers and power storage modules should be discharged at rates in increment of 0.1 V
(TBD) up to the maximum declared discharge rate.
8.3.4. Power Storage Capacity

8.3.4.1.
Power Capacity - Speci;cations
The power budget of an Ara phone is dependent on accurate representation of total and
instantaneous remaining capacities declared by individual power storage module. To ensure
that the device power gauge is accurately represented from the aggregate capacities of all
January 8, 2015
Page 97 of 107
power storage modules, the declared capacity of power storage modules must be veri;ed
through a load test.
8.3.4.2.
Power Storage Capacity - Prototype Reference Implementation
8.4.
Network Compliance
8.4.1. M-PHY Compliance

8.4.1.1.
M-PHY Compliance - Speci;cations
Module must comply with M-PHY speci;cations including the contactless media converter as
de;ned in the Network section. Compliance is necessary to communicate on the switch
network, but it is equally important to ensure a module will not be able to interfere with the
switch or other modules on the network.
Standards-compliant COTS M-PHY protocol test suite and test equipment should be used to
verify the module M-PHY implementation in all applicable modes including burst mode
operation, multiple transmission modes with diGerent bit-signaling and clocking schemes,
multiple transmission speed ranges/rates per burst mode, multiple power saving modes,
symbol coding (8b10b) for spectral conditioning, clock recovery, and in-band control options
for both PHY and Protocol level, clocking Qexibility, electro-optical signal conversion and
optical data transport inside the interconnect, and module con;gurability. A network analyzer
and oscilloscope should be used to verify all relevant CMC parameters provided in the CMC
speci;cations.
8.4.1.2.
M-PHY Compliance - Prototype Reference Implementation
Developers should utilize the MIPI approved M-PHY protocol test suite and calibrated test
equipment. Relevant test con;guration will be provided in a future MDK release.
8.4.2. UniPro Compliance

8.4.2.1.
UniPro Compliance - Speci;cations
Module must comply with UniPro speci;cations as de;ned in the Network section. Compliance
is necessary to communicate on the switch network, but it is equally important to ensure a
module will not be able to interfere with the switch or other modules on the network.
Standards-compliant COTS UniPro protocol test suite and test equipment should be used to
verify the module UniPro implementation in at the data link, transport, and network layers.
January 8, 2015
Page 98 of 107
Compliance testing should be consistent with the UniPro Working Groups Conformance Test
Suite (CTS) and Protocol Implementation Conformance Statement (PICS).
8.4.2.2.
UniPro Compliance - Prototype Reference Implementation
Developers should utilize the MIPI approved UniPro protocol test suite and calibrated test
equipment. Relevant test con;guration will be provided in a future MDK release.
8.4.3. Layer 5+ Greybus Compliance

8.4.3.1.
Layer 5+ Greybus Compliance - Speci;cations
Module must comply with Layer 5+ Greybus speci;cations as de;ned in the Network and
Software sections. Future MDK releases will provide relevant test suites to demonstrate
Greybus speci;cation compliance.
8.4.3.2.
Layer 5+ Greybus Compliance - Prototype Reference Implementation
8.5.
Software Compliance
8.5.1. Kernel Compliance

8.5.1.1.
Kernel Compliance - Speci;cations
Module must comply with kernel speci;cations as de;ned in the Software section.
8.5.1.2.
Kernel Compliance - Prototype Reference Implementation
8.5.2. Android Compliance

8.5.2.1.
Android Compliance - Speci;cations
Module must comply with Android speci;cations as de;ned in the Software section.
January 8, 2015
Page 99 of 107
8.5.2.2.
Android Compliance - Prototype Reference Implementation
Compliance test procedures for Ara modules will include the standard Android Compatibility
Test Suite plus additional procedures for Ara-speci;c features such as hotplug support.
Details of the Ara-speci;c compliance test procedures will be provided in a future MDK
release.
8.6.
System-Level Functions Compliance
8.6.1. Wake/Detect Compliance

8.6.1.1.
Wake/Detect Compliance - Speci;cations
Module must comply with Wake/Detect speci;cations as de;ned in the System-Level
Functions section.
8.6.1.2.
Wake/Detect Compliance - Prototype Reference Implementation
8.6.2. Hotplug Compliance

8.6.2.1.
Hotplug Compliance - Speci;cations
All modules except Display and AP Modules must comply with hotplug speci;cations as
de;ned in the System-Level Functions section.
8.6.2.2.
Hotplug Compliance - Prototype Reference Implementation
January 8, 2015
Page 100 of 107
9.
Ara Module Marketplace
This section provides an overview of the Ara Module Marketplace, an e-commerce portal that
enables a two-sided market between module developers and consumers. The main
components of the Ara Module Marketplace are the developer-facing Ara Developer Console
and the Ara Con;gurator app that users will be able to access on their Ara phone.
Additionally, this section provides preliminary guidance on submission, review process, and
sale of Ara modules through the Ara Module Marketplace. This section only applies to
developers who intend to make their modules available for sale through the Ara Module
Marketplace.
9.1.
Ara Developer Console
The Ara Developer Console is the primary developer-facing element of the Ara Module
Marketplace and serves as the main entry point for module vendors and developers. The web
portal address will be provided in a future MDK release.
9.1.1. Signup and Module Submission

The Ara Developer console will require a Google Account for signup. After signup, module
developers and vendors will be able to submit a module oGering for a pre-de;ned review
process to ensure modules are compliant with the speci;cations outlined in this MDK
document. Compliance with these speci;cations, including any applicable regulatory and
certi;cation requirements (see section 10 of this document), is required for all modules prior to
being listed for sale in the Ara Module Marketplace.
Module developers must provide a Tech Data Package (TDP) and Module Support Package
(MSP) as part of their module submission to Google. The TDP and MSP include a preliminary
set of items listed in Tables 9.1 and 9.2 respectively. The TDP enables Google to verify modules
are compliant with the MDK, while the MSP enables the distribution of software packages
required for any Module functionality beyond generic class driver speci;cations. Future MDK
releases will provide additional guidance on TDP and MSP requirements and the submission
process.
January 8, 2015
Page 101 of 107
Table 9.1 - Tech Data Package Items (TBD)

Item
Description
CAD Model
3D model of modules in STEP format
2D Drawings
2D line drawings and tolerance data of any module components that

are diGerent than the reference materials in PDF format
Electrical Model
Electrical schematics and layout showing module component

interfaces with Interface Block connections in EDA and PDF formats
Software
Android software required for module to function
M-PHY, UniPro Source
Source of M-PHY and UniPro implementation, e.g. Toshiba Bridge

ASIC
Custom Shell CAD
CAD model of module shell if diGerent than standard shell in STP

format (should include antenna LDS pattern if module has an antenna
in the shell)
Custom Shell Drawings
2D line drawings of module shell if diGerent than standard shell in PDF

format (should include antenna LDS pattern if module has an antenna
in the shell)
Performance Specs
Module speci;c performance speci;cations, e.g. for a WiFI module:

band(s), data rates, encryption
Composition Requirements
Dependencies on other modules, e.g., presence of certain sensors,

minimum AP or display performance, etc.4
Table 9.2 - Module Support Package Items (TBD)
Item
Description
Power Pro;le
Expect power draw and/or power discharge rates in xml format

(TBD)
Bridge Info
Make and model of UniPro Bridge IC
Firmware
Additional ;rmware required for module to function
Additional Software (TBD)
Additional software required for module to function
9.1.2. Module Merchandising Data

Once modules are accepted into the Ara Module Marketplace, module developers and vendors
should provide some merchandising data to be used on the Ara Module Marketplace. This
4A more formal way of characterizing inter-module dependencies and their impact on user
features/performance is anticipated in a future release of the MDK.
January 8, 2015
Page 102 of 107
includes, but is not limited to the items provided in Table 9.3.

Table 9.3 - Module Merchandising Data
Merchandising Data
Description
PID
Part ID, assigned by module developer
Short Name
Module name
Short Description
Description text for consumers
Primary Image
Main image of the module
Additional Image(s)
Additional module images
Module Category
Primary module category
Secondary Label(s)
Additional labels for tagging purposes
Price
Module price
Availability
Regional availability
Size
Module size (1x1, 1x2, 2x2, Front A, etc)
Requirements
Requirements for operation; two strings: title and description
Technical Speci;cations
Module technical speci;cations; two strings: title and description
9.1.3. Sales Metrics and Performance Tracking

The Ara Developer Console will allow tracking performance metrics that can be used to
manage module oGering forecasting and planning. These include revenue and sales ;gures,
dead on arrival (DOA) and buyers remorse return information, and user insights.
9.1.4. Payments Disbursement

Revenue associated with module sales will be disbursed periodically at a set interval TBD.
Module developers and vendors must provide bank account information to receive payment for
module sales.
9.2.
Logistics and Distribution
In supported geographies, modules will need to be shipped to a warehouse managed by a preselected third party logistics provider who will handle both shipping and returns. Commercial
agreements, pricing, will be negotiated between the developer and the logistics provider on a
case-by-case basis.
January 8, 2015
Page 103 of 107
9.3.
Module Identi$ers
Each module must have several electronically programmed identi;cation numbers. Table 9.4
provides the ID ;elds and size required. Once programmed, this information must be
immutable. The ID information should be accessible by the supervisory controller through the
UniPro network.
Table 9.4 - Module Identi$cation Numbers
ID Type
Description
Size
VID
Vendor ID, assigned by Google
32 Bits
PID
Part ID, assigned by module developer
32 Bits
SN
Serial number, assigned by module developer
64 Bits
The vendor ID ;eld is a value assigned by Google. All vendors should apply for a Project Ara
vendor ID in order to properly mark their modules. Contact ara-dev@google.com for more
information regarding the vendor ID application process.
The part ID ;eld is assigned by the module vendor or developer. The part ID should represent a
particular and unique model of the module.
In addition to the VID and PID values, each module must have information that can be used to
uniquely identify the module from any other module. Modules using Toshiba Bridge ASICs can
leverage the unique Internal Master Secret (IMS) value, which is programmed by Toshiba.
Modules that utilize another Bridge ASIC or UniPro implementation must provide a
corresponding compliant mechanism.
January 8, 2015
Page 104 of 107
10. Regulatory Compliance and Carrier Certi;cation

This section provides a brief overview of regulatory and carrier certi;cation requirements for
Ara module developers. It should not be considered as legal advice and is not intended to be
comprehensive or de;nitive. Developers are responsible for ensuring that their modules comply
with all applicable laws and regulations, including regulatory requirements of the Federal
Communications Commission, the Food and Drug Administration, the Consumer Product
Safety Commission, and other regulatory agencies, as applicable to target markets. Developers
should consult oTcial regulations to ensure compliance.
10.1. US Regulatory Compliance and Carrier Certi$cation

The following subsections provide some general guidance on radio frequency (RF), medical
device, and carrier certi;cation requirements in the US.
10.1.1.
US RF Regulatory Authorization
The Federal Communication Commission (FCC) regulates certain RF-emitting devices in the
US to limit the devices potential to cause harmful interference to radio communications and to
ensure that consumers are not exposed to unsafe levels of radiation.
10.1.1.1.
FCC Equipment Authorization - Speci;cation
Exposure standards for radiofrequency energy have been developed by various organizations
and countries. These standards recommend safe levels of exposure for both the general
public and for workers. In the United States, the FCC has adopted and used recognized safety
guidelines for evaluating RF environmental exposure. The exposure limits used by the FCC are
expressed in terms of speci;c absorption rate (SAR), electric and magnetic ;eld strength and
power density for transmitters operating at frequencies from 300 kHz to 100 GHz. The FCC
authorizes and licenses devices, transmitters and facilities that generate RF radiation.
The FCC rules prescribe a set of equipment authorization (EA) procedures designed to con;rm
the regulatory compliance of RF-emitting devices prior to importation or marketing in the US.
For low-powered digital devices that do not intentionally emit RF energy, the FCC requires a
veri;cation procedure that involves the manufacturer con;rming devices operate within the
appropriate technical standards. On the other hand, consumer devices like cellular phones that
utilize licensed radio frequencies require a more extensive certi;cation procedure that includes
testing to ensure RF emissions are below the safe threshold for SAR and do not cause
interference. The certi;cation procedure also involves an oTcial application ;ling with the FCC
or a Telecommunication Certi;cation Body (TCB) and associated fees.
10.1.1.2.
FCC Equipment Authorization - Reference Implementation
FCC EA procedures for various module types will be provided in a future MDK release.
January 8, 2015
Page 105 of 107
10.1.1.2.1.
FCC Equipment Authorization - Reference Implementation for Hobbyist/Maker
Per 47 CFR 15.23, an equipment authorization is not required for devices that are not marketed
and are built in quantities of ;ve or less for personal use. While the exemption applies to Ara
modules developed for personal use, developers should use good engineering judgement to
ensure compliance with frequency and device safety guidelines including those speci;ed in this
document. The exemption, moreover, does not apply to devices that are built from a kit. Note
that the provisions of 47 CFR 15.5 (specifying general conditions of operation) apply to this
equipment.
10.1.1.2.2.
FCC Equipment Authorization - Prototype/Experimental License
Per 47 CFR Part 5, an experimental license (or Special Temporary Authorization for
experiments of shorter duration) is required to utilize radio spectrum during ;eld
experimentation, product development, and market trials. The majority of prototype
development is not expected to involve radios; however, if a module developer requires an
experimental license, they may obtain one directly from the FCC through the experimental
license system.
10.1.2.
US Medical Device Regulation
The US Food and Drug Administration (FDA) regulates medical devices in the US.
10.1.2.1.
FDA Regulation - Speci;cation
The FDA regulates medical devices in the US. The de;nition of medical devices include
devices intended for the diagnosis of disease or other conditions, or in the cure, mitigation,
treatment, or prevention of disease, or devices intended to aGect the structure or any function
of the body. The FDA de;nes three classes of medical devices and associated regulatory
procedures. Device classi;cation depends on the intended use of the device and also upon
indications for use (see the FDA website for more information on how to classify a medical
device). Most Class 1 devices are exempt from Premarket Noti;cation 510(k); most Class 2
devices require Premarket Noti;cation 510(k); and most Class 3 devices require Premarket
Approval.
10.1.2.2.
FDA Regulation - Prototype Reference Implementation
None at this time.
10.1.3.
Carrier Terminal Acceptance
Carrier Terminal Acceptance requirements for a module depend on the radio access
technology (e.g. 3G/ 4G LTE), the licensed frequency bands of operation, and services
(voice/data/SMS) supported.
January 8, 2015
Page 106 of 107
Lab and ;eld tests are required to validate radio and physical layer characteristics, protocol
implementation and network performance. Standardized test speci;cations cover signaling
conformance, radio transmission and reception, and radio resource management. System
performance and interoperability tests include over-the-air radiated power transmission, SIM
interaction, network selection, call performance, data throughput and user experience.
10.2. International Certi$cation

TBD
January 8, 2015
Page 107 of 107

AraMDK 0.2

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

AraMDK 0.2

Diunggah oleh

Hak Cipta:

Format Tersedia

Project Ara

Module Developers Kit (MDK)

Release 0.2 (alpha)

Welcome. What now?

Marti Bolivar, Perry Hung, Andrew Meyer

New Deal Design

Dan Clifton, Gadi Amit, Inbal Etgar, Susan McKinney

Sandeep Neema, Ted Bapty

Yukio Watanabe, Toshihide Fujiyoshi, Takuma Aoyama, Kaoru Kamata,

Fabien Parent, Alexandre Bailon, Benoit Cousson

Jason Chou, Shan-Ting Hsu, Sutchaya Lertburapa, Pitt Lin, Mickey Ge

Peter Woodd, Kevin Baumber, Sangsoo Yim

Application Binary Interface

Application Programming Interface

Application Speci;c Integrated Circuit

Contactless Media Converter

Color, Material, Finish

Camera Serial Interface

Display Serial Interface

Electronic Design Automation

Field Programmable Gate Array

General Purpose Bridge ASIC

General Purpose Input Output

Global Positioning System

Hardware Abstraction Libraries

High-Speed Bridge ASIC

High-Speed Inter Chip (USB)

Inter Integrated Circuit

Integrated Interchip Sound

Internal Master Secret

Intellectual Property (generally not Internet Protocol)

Low-Voltage DiGerential Signaling

Module Developers Kit

Refers to mobile industry standards alliance

MIPI Physical Layer Speci;cation

Module Support Package

Open Systems Interconnection

Printed Circuit Board

Pulse Width Modulation

Resistor-Capacitor (i.e., RC circuit)

Remote Host Controller

Real-time Operating System

Secure Digital Input Output

Scalable Low-Voltage Signaling

Standard for the Exchange of Product Model data

Tech Data Package

Universal Flash Storage

MIPI Uni;ed Protocol

Universal Serial Bus

The Ara MDK License

1.2.5. Prototype Platform External Licenses

Spine (Endo Spine)

Rib (Endo Rib)

The orientation of the primary display module determines the top of

Phone Coordinate Axes

The Endo contains electro-permanent magnets (EPMs) to attach and

Figure 2.1 - Ara Phone Built Based on Medium Endo

Figure 2.2 - Ara Endo (Medium Variant)

2.2.1. Rear Parceling Scheme

Endos must have exactly one vertical spine.

Figure 2.4 - Valid Medium Endo Con$gurations (Rear)

Figure 2.5 - Rear Modules

2.2.2. Front Parceling Scheme