Project ara report 2

Project Ara Seminar Report

Indira Gandhi College Of Arts & Science 1 BSc Computer Science

1. INTRODUCTION

Project Ara is the codename for an initiative by Google that aims to develop an open hardware

platform for creating highly modular smartphones. The platform will include a structural frame that

holds smartphone modules of the owner's choice, such as a display, keyboard or an extra battery. It

would allow users to swap out malfunctioning modules or upgrade individual modules as

innovations emerge, providing longer lifetime cycles for the handset, and potentially reducing

electronic waste. The first model of the modular phone is scheduled to be released in January 2015.

The project was originally headed by the Advanced Technologies and Projects team within Motorola

Mobility while it was a subsidiary of Google. Although Google had sold Motorola to Lenovo, it is

retaining the project team who will work under the direction of the Android division.

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. Ara’s success is predicated on a

rich, vibrant, and diverse ecosystem of modules from developers. Users would be able to select

modules from an online marketplace using a configurator that facilitates user choice and curates the

configuration process to ensure that the selection of modules provides the expected system-level

functionality.

Project Ara is a platform for creating modular smartphones. Users will be able to populate 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 phone’s 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. Ara’ssuccess 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 configurator that facilitates user

choice and curates the configuration process to ensure that the selection of modules provides the

expected system-level functionality.



Figure 1.1 Project Ara



2. PROJECT ARA AN OVERVIEW

Project Ara an overview

Developer Google

Manufacturer User

Type Smartphone

Release date 2015

Introductory price minimal cost ~US$50

Operating system Android

Power Variable

System-on-chip used Variable, Toshiba-supplied for the first year

CPU Variable

Memory Variable

Storage Variable

Display Variable

Graphics Variable

Sound Variable

Input Variable

Camera Optional

Connectivity Variable

Dimensions Variable

Weight Variable

Table 2.1- Project Ara overview.



3. GENERAL HARDWARE ARCHITECTURE

Figure 3.1: Ara Endo (Medium Variant)



Figure 3.2 - Ara Phone Built Based on Medium Endo

The Ara architecture requires the introduction of several new concepts to the traditional mobile

device lexicon. These terms are defined in the following table.

Term Definition

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 affordance such as thedisplay,

speaker, microphone, etc., and rear modules, which provide

the bulk of the phone’s back-end 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 fit into multiple frame sizes.



Endoskeleton (Endo)

The Ara endoskeleton (“endo”) is the frame 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

Large, with varying rib configurations for each.

Spine (Endo Spine) A singular vertical feature that bisects the rear of the endo

and forms part of the module slots.

Rib (Endo Rib) Horizontal features located either in the front or the rear of

the endo and forms part of the module slots.

Top The orientation of the primary display module determines the

“top” of the Phone.

Phone Coordinate Axes (X, Y, Z) The Ara platform uses the Android defined coordinate

system. The Side-to-Side direction defines the X axis. The

Top-Bottom direction defines the Y axis. The thickness

direction defines the Z axis.

Interface Block The interface block is the area on theendo and the modules

where the electrical power pins and capacitive data pads are

located.

Electro-Permanent Magnets (EPM) Rear modules attach and secure themselves to the endo with

electro permanent magnets (EPM) directly, whereas front

modules utilize pins for attachment to the endo.

Module Shell The module shell is a user-replaceable cover for Ara modules

that can be aesthetically customized and is 3D printed as part

of the Ara fulfillment Process.

Table 3.1 – Terms and definitions.

4. DESIGN LANGUAGE

The design language is a set of design elements used to visually communicate a specific 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 different sources.



4.1 DESIGN LANGUGE - SPECIFICATION

The overall goal of the module aesthetic is to create a smooth, fat, 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, finish (CMF)

guidelines. Table 4.1.1 summarizes the geometric guidelines. CMF guidelines will be provided in a

future release

Guideline

Illustration

Module side profle must

conform to the shape of

the endo. This is not

onlynecessary to follow

the design language, but

is also critical to allow

the modules to slide into

module slots in the

endoandlock into place.

Modules taller in Z

should continue the

trapezoid form while

expanding in Z.



The side profle sections

should be symmetric

across X and Y axes.

Corners should have 1.5

mm curvature radii.

Modules should keep

rectilinear footprints

when possible; these are

exemplified by 1.5 mm

rounded corners

connected by straight

lines.

Planar surfaces (meeting

at angles) do not need to

be parallel or

perpendicular to the

module’s bottom surface



5. MODULE GEOMETRY AND ASSEMBLIES

Figure 5.1 -Rear Modules

All rear modules should nominally support user-replaceable module shells. Module shells attach to

rear modules via mechanical snap-fit features built into the module base and shell itself. Replaceable

module shells are a unique feature of the Ara architecture. They allow users to leverage consumer-

grade, full-color 3D printing to aesthetically customize their Ara phone before purchase, and if

desired, to replace each module shell any time thereafter. The 2x2 modules may support an optional

second interfaces block for increased power and data utilization. All three rear module types are

composed of three sub-assemblies: the module base, printed circuit board (PCB), and safety shield.



Figure 5.2 -Rear Module Sub-assemblies(1x2 module)

The PCB contains the circuitry for the module, including the endo interface functionality, as well as

the custom functionality of the module. Any non-electronic components that are part of the

Module (e.g., batteries, sensors) must either mount to or in place of the PCB. Table 5.1 provides

maximum dimensions available for rear module PCBs. PCBs smaller than these dimensions are

allowed. Note that interface block(s) and EPM(s) (and driver circuits) will take up some of the

available PCB areas. The PCB must mount to the module base.

Rear Module

PCB Maximum Dimensions (X, Y)

1x1

18 mm x 18 mm

1x2

18 mm x 40.5 mm

2x2

39.5 mm x 41 mm

Table 5.1 - Rear Module Maximum PCB Dimensions



6. ELECTRO-PERMANET MAGNETS (EPM)

The EPMs provide a low-power and user-controllable method to securely attach modules to Slots in

the endoskeleton. The EPM has two selectable states: the attach state and release State,

corresponding to high and low levels of magnetic force. Electrical power is needed to Switch

between the two states only; the EPMs require no sustained electrical power to maintain Either state.

EPMs in the attach state provide sufficient magnetic force to secure modules into their slots on the

endo throughout all nominal usage scenarios. EPMs in the release state provide a residual magnetic

force to prevent modules from falling out unless the user deliberately removes the Module from the

endo. Users should be able to remove modules with minimal effort when the EPM is in the release

state.

The 1x1 and 2x2 modules each use a single EPM. 1x2 modules use two EPMs, one for each Valid

module insertion direction. Each EPM must provide a minimum holding force of 30 N in the

attached state, and 3 N in the release state. This force must be applied in the insertion Direction of

the module, i.e., in the X direction. The EPM attachment surfaces on the endo are made from

Hiperco-50 alloy to provide enhanced magnetic holding force.



Figure 6.1 - Rear Module EPM Exploded View

Figure 6.1 shows an EPM used in the prototype. The front curved face mates with theHiperco-50

attachment surface on the endo spine. The EPM is made from three parallel Sections. The N42SH

magnets at the front are magnetized parallel to the long axis of the device, alternating magnetization

direction from section to section. The Alnicomagnetsin the back can have their magnetization

direction reversed by passing a current through the coils.When the Alnicomagnets are magnetized

opposite to the N42SH magnets, the holding forceis low; this is the release state. When the Alnico

and N42SH magnets are magnetized together, the holding force is larger; this is the attach state.



7. 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 different configurations depending on the location of the ribs and spine.

7.1 REAR PARCELING SCHEME

The rear of the endo is parceled into 1x1 unit squares. Each 1x1 square is approximately 20mm.

Note, however, that 1x2 and 2x2 modules are not exactly 20x40mm and 40x40mm due to the fact

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.

Endos must have exactly one vertical spine.

● The Medium variant spine must be at a 1:2 horizontal offset from

the centerline of the device as viewed from the rear.

● The Mini and Large (TBD) 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 confgurations

for each size variant.



7.2 FRONT PARCELING SCHEME

The following design rules govern the front parceling scheme:

● Vertical spines are not allowed - all modules must fll 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 shows the valid set of front endo configurations for each size variant,

labeled A through L. Front modules for the Large endo variant will be formalized in a future MDK

release



Figure 7.2.1 front parceling schemes



8. POWER ARCHITECTURE

The Ara power architecture is designed to accommodate the unique and flexible 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 of 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 flexible power

platform for new applications.

Figure 8.1 shows a high-level view of the Ara power architecture. A common power bus is Central to

the architecture. The power bus is held between 3.0 and 5.5 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 overcurrent. 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 reconfigured 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 module’s charging port is active), a charging module when powered throughits charging

port, and a power storage device when functioning as a regular battery. Figure 8.1 also illustrates a

simplified view of these three module types.



Figure 8.1 -Power Architecture

8.1 POWER CONSUMER MODULE

At the top of Figure 8.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.



8.2 CHARGER MODULE

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 EPM activation and the module

enumeration process, but current flows nominally in one direction, from the module to the bus. A

traditional DC charger module is shown in Figure 8.1

8.3 POWER STORAGE MODULE

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. Ideal diode

circuits prevent current flow into a battery, and, therefore the power bus voltage is equal to the

highest voltage presented by any of the batteries connected to the power bus. 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 (central power management system) via Uni Pro messaging. The

supervisory controller then signals battery modules to cut of 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.



9. EXTENDED ARCHITECTURE

The envelope for a module comprises the standard dimensions for the module to conform to the Ara

endos. While a module will ideally fit within these very specific 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 9.1 provides the absolute

maximum exceedence limits, driven by the capability of 3D printers (to print the associated module

shells); however, module developers should also use good engineering judgment 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

user’s pocket. Modules with dimensional exceedances must have a custom safety shield and ensure

all electrically active components are encapsulated within.

Direction

Max Dimension

Notes

X

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.

Y

20 cm

Overall module height must not

exceed this figure.

Z

2.5 cm

Overall module thickness must

not exceed this figure.

Table 9.1 - Envelope Violation Limits



Exceedances may be appropriate and necessary for some applications as demonstrated in figures 9.2

and 9.1 Figure 9.2 is a reflective Pulse Oximeter Module, which measures blood oxygen saturation.

The exceedance in the Y dimension provides a convenient affordance and sensor location for a user’s

finger. Figure 9.1 is an example of a Prototype Thermal Imager Module. The exceedance in the Z

dimension enables modules to accommodate components with high thickness requirements such as a

camera lens unit.

Figure 9.1 - Pulse Oximeter Module with Y-Dimension Exceedance



Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance



10. SOFTEARE ARCHITECTURE

The Ara software stack is predicated on the attachment of a single Application Processor (AP)

Module running Android (Support for multiple AP modules may be included in a future). From the

perspective of an Ara phone’s Linux kernel, there are two types of modules: those which conform to

a particular device class (device classes such as cameras, displays, human interface devices, etc.),

and novel, unique, or otherwise special-purpose modules, which do not belong to any device class.

Devices without in-kernel device class drivers are unlikely to have native UniPro interfaces. These

devices will communicate with Android through a UniPro Bridge chip driver in the kernel and a

developer-supplied Userspace driver. Figure 10.1 shows the software interfaces and interactions for

modules with and without existing in-kernel device class drivers.

Figure 10.1 - Software Architecture



10.1 KERNEL DRIVERS

Linux device drivers provide low-level hardware support on Android devices. On a

standardSmartphone, the available hardware is fixed, allowing device manufacturers to pre-select a

set ofdevice drivers. On an Ara phone, however, almost all of the hardware which is normally an

immutable part of a smartphone’s design is designed to be user replaceable and hot pluggable.

To enable hot-plug support and provide a framework that enables arbitrary future extensions, two

driver classes will be developed, as previously shown in Figure 10.1 native UniPro-based class

drivers and UniPro Bridge ASIC-based user mode drivers. UniPro class drivers will support a range

of module devices with in-kernel device drivers that will be part of the base Ara software release.

The UniPro Bridge ASIC drivers will allow a module device without native UniPro interface or in-

kernel device driver to communicate with Android through the Linux driver core and a developer-

supplied userspace driver. The design of this interface is influenced by the file system in Userspace

(FUSE) project.

10.2 ANDROID HALS

Hardware Abstraction Libraries (HAL) are implemented as shared libraries; their code runs within

Android’s system services. Unlike device drivers, HAL APIs are specified by Google andare 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

different hardware peripherals those services must control.

10.3 ANDROID APPLICATION

In general Android applications for the Ara platform are not in any significant respect different than

traditional Android apps. Consequently, Ara devices are anticipated to be compatible with most

standard apps.



11. SYSTEM-LEVEL FUNCTIONS

The following are the system-level functions performed by Ara modules. Modules will utilize the

network and software stacks to exercise these functions. Modules interface with the supervisory

controller in the endo to carry out these functions.

11.1 MODULE DETECT

A feature of the Ara platform is that batteries and power buttons can be distributed among the

modules. The platform uses out-of-band wake and detect signals to allow modules and the endo to

power themselves of when appropriate. The 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 off. Modules with batteries must place

themselves in a powered-down standby state when they lose the detect signal from the endo.

An Ara phone can power itself on and offby pressing buttons on a module. The wake signalsare used

to bring the phone out of a low-power standby state. The WAKE_TX signal is sent from a module to

the supervisory controller when the power button is pressed. This brings the supervisory controller

out of standby state, and the supervisory controller, in turn, sends WAKE_RX signals to each of the

installed modules to turn them on.

11.2 ENUMERATION

Enumeration allows the phone to identify and determine the capability of a module when it is

plugged into the endo. 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

identifier needed to operate the module. When a module insertion event occurs, the UniPro switch on

the endo signals an interrupt to the supervisory controller. The supervisory controller then establishes

a low-speed link with the module and initializes the device identification. The supervisory controller

then sends a UniPro message to the other modules, including the Application Processor to announce

the insertion event so appropriate drivers can be loaded.



11.3 EPM CONTROL

EPM control addresses how EPM(s) in the module are switched between attach and release states.

These actions are triggered by the user with an application interface. The application will graphically

show the current state of modules and module slots in the phone including whether a module is

present in the slot, the name identifier of a module, and the state of the module’s EPM(s)

(attach/detach). The user may then toggle the state of the EPM by touching on a specific module.

Once triggered by the user, the supervisory controller issues EPM control messages to activate the

EPM driver circuits

11.4 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 measurements to the supervisory

controller. If temperatures exceed predefined limits, modules may receive warnings, and in the worst

case, power will be removed.Active thermal management is not implemented in the prototype

platform.



12. ADVANTAGES

PRICE

The basic Project ARA phone is going to cost less than $50 to manufacture making it accessible to

almost everyone.

CHEAPER REPAIRS

If a screen breaks, you just replace that. The same will be true with any module. Hopefully there will

be some sort of diagnostic built in so whatever breaks, you can just swap the part out.

CUSTOMIZATION

You only need to add in what you need.so you need to pay only for what you want.

INCREASED LIFE

You just upgrade as you require or as parts break so you never need to buy a whole new phone.

This will also result in less waste.

BATTERY LIFE

By having 2 or more battery’s, phone will last longer and being able to how swap modules should

mean that you can keep your phone going as long as you need.

SUPPORT SPECIALISATION

You may have specialized modules that you onlyswap in when you need them.



13. DISADVANTAGES

SIZE OF THE PHONE

In the early days Project ARA phone is not going to be as slim as a traditional phone. Height and

width will not be an issue, because people want big phones but thickness could be a problem.

TESTING ISSUE

Expect more bugs with an ARA phone. Even with only a handful of modules, there will be a huge

number of combinations and it will be almost impossible to test them all. With the open module

development environment, there will be ARA modules from a huge number of suppliers which can’t

all be tested together.

DESIGN

Due to the modular architecture, project ara is can’t offer attractive designs which is offered by

todays smart phones.



14. CONCLUSION

● One field that is benefitting from this project is 3D printing

● Specialized technology (UniPro and M-PHY) has made the development of this

device efficient

● Technology used in Project ARA can be re-used in other items

● Modular market might not settle so quickly

● With the prototype’s receive in the market, new companies or individuals might get

interested in the development of modules

● The success is tightly connected to the variety of modules and brands that the user

might be able to acquire

● The platform that allows the user to manage all its modules should be intuitive

enough for new smartphone users



15. BIBILIOGRAPHY

[1]. PHONEBLOKS. Phonebloks, a phone worth keeping. 2014. https://phonebloks.com/en

[2]. REISINGER, Don. Report: Google acquires Modu's mobile patents.

20/05/2011. http://www.cnet.com/news/report-google-acquires-modus-mobilepatents/

[3]. THUNDERCLAP.INC. Thundeclap. 2012 https://www.thunderclap.it/en

[4]. MCCRACKEN, Harry. Project Ara: Inside Google’sBold Gambit to Make Smartphones Modular.

26/02/2014. http://time.com/10115/google-project-aramodular-smartphone/

[5]. YUE, Yu. Two Futuristic ZTE Phones. 29/10/2013

http://wwwen.zte.com.cn/endata/magazine/mobileworld/2013/5/articles/2013

10/t20131029_411072.html

[6]. PÉREZ, Alex. Smartphone modular Xiaomi Magic Cube. 10/10/2013.

http://www.movileschinos.eu/noticias/xiaomi-magic-cube/

[7]. BLOCKS. Choosebloks. 2014. http://www.chooseblocks.com/

[8]. CHAN, Norman. Tested Explains: How Google's Project Ara Smartphone Works.

15/04/2014 http://www.tested.com/tech/smartphones/460765-tested-explains-howgoogles-

project-ara-smartphone-works/

[9]. GOOGLE ATAP. Project Ara Developers Conference Day1. 15/04/2014.

https://www.youtube.com/watch?v=v2OEKL1w__4

[10]. GOOGLE ATAP. Project Ara Developers Conference Day2. 15/04/2014.

https://www.youtube.com/watch?v=cP8yzJhe-BA

[11]. MIPI ALLIANCE. UniPro(SM) Specifications. 2014. http://mipi.org/specifications/unipro-

specifications



[12]. MIPI ALLIANCE. Physical Layer Specifications. 2014.

http://mipi.org/specifications/physical-layer

[13]. DEYLE, Travis. Electropermanent Magnets. 7/12/2010

[14]. http://www.hizook.com/blog/2010/12/07/electropermanentmagnets-programmable-magnets-

zero-static-powerconsumption-enable-s

Project ara report 2

Documents

ara phone

selection of modules

smartphone modules

individual modules

malfunctioning modules

overview project ara

project ara overview

ara architecture