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

More Related Content

What's hot (18)

Similar to Project ara report 2 (20)

More from Georgekutty Francis (11)

Project ara report 2