SlideShare a Scribd company logo

14 575

•
•
Chaitanya Ram
Chaitanya Ram

Project Ara is a modular smartphone platform developed by Google that allows users to customize their phone by swapping modules. The platform includes an endoskeleton frame that holds interchangeable modules for functions like display, camera, battery. This modularity provides longer usage by allowing users to replace broken modules or upgrade individual parts. The first developer version is scheduled for late 2016 with a basic phone costing around $50. Success depends on a vibrant ecosystem of third-party developed modules.

Related slideshows

Ijmsr 2016-02
Ijmsr 2016-02Ijmsr 2016-02
Ijmsr 2016-02
 
Project ARA
Project ARAProject ARA
Project ARA
 
project ara
project araproject ara
project ara
 
1 of 31
Download to read offline
1 A seminar report on PROJECT ARA (Modular Phones) BY K.V.G.SATISH 14A81A0575 (Under the guidance of MR.J.VIJITHANAND, M.TECH) DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING SRI VASAVI ENGINEERING COLLEGE Pedatadepalli, Tadepalligudem-534101, W.G.Dist, AndhraPradesh, 2016 - 17
2 INDEX Content Name Page No. 1. Introduction 1 2. Project ara an overview 3 3. General Hardware Architecture 4 4. Design Language 6 4.1 Design Language – Specification 6 5. Module Geometry and Assemblies 8 6. Electro-Permanent Magnets (Epm) 10 7. Parceling Schemes 12 7.1 Rear Parceling Scheme 12 7.2 Front Parceling Scheme 12 8. Power Architecture 14 8.1 Power Consumer Module 15 8.2 Charger Module 16 8.3 Power Storage Module 16 9. Extended Architecture 17 10. Software Architecture 20 10.1 Kernel Drivers 21 10.2 Android Hals 21 10.3 Android Application 21 11. System-Level Functions 22 11.1 Module Detect 22 11.2 Enumeration 22 11.3 Epm Control 23 11.4 Active Thermal Management 23 12. Advantages 24 13. Disadvantages 25 14. Conclusion 26 15. Bibliography 27
3 LIST OF FIGURES Figure Name Page No. Figure 1.1 Project Ara 2 Figure 3.1: Ara Endo (Medium Variant) 4 Figure 5.1 -Rear Modules 8 Figure 5.2 Rear Module Sub-assemblies(1x2 module) 9 Figure 6.1 - Rear Module EPM Exploded View 10 Figure 7.2.1 front parceling schemes 13 Figure 8.1 -Power Architecture 15 Figure 9.1 - Pulse Oximeter Module with Y-Dimension Exceedance 18 Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance 19 Figure 10.1 - Software Architecture 20
4 ABSTRACT Project Ara is the codename for an unnamed modular smartphone that is essentially a computer board with compatible modules. The platform will include a endoskeletal frame with modules of the owner's choice, such as a display, camera or an extra battery. The phone itself can be swapped from malfunctioning modules or upgrades as innovations emerge, providing longer handset cycle lifetime, and potentially reducing electronic waste. ProjectAra smartphone is scheduled to release a developer version in the United States in the fourth quarter of 2016 with a target bill of materials cost of $50 for a basic grey phone.A consumer version is not expected until at least 2017. The project was originally headed by the Advanced Technology and Projects team within Motorola Mobility while it was a Google subsidiary. Although Google has since divested Motorola to Lenovo, it retained the ATAP group, now a division under Android.The project separated from ATAP and is now an independent division.
5 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’ssuccess 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.
6 Figure 1.1 Project Ara
7 5. PROJECTARAANOVERVIEW 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.
8 6. GENERAL HARDWARE ARCHITECTURE Figure 3.1: Ara Endo (Medium Variant) 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
9 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 endosslots, which hasa 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 Arafulfillment Process. Table 3.1– Terms and definitions.32
10 4. DESIGN LANGUAGE The design language is a set of design elements used to visually communicate a specificaesthetic. Implementing a consistent design language ensures that every Ara phone has a set of aesthetically cohesive modules, even though each phone may include modules fromdifferent 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 tounderstand 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 ina 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.
11 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
12 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.
13 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
14 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
15 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.
16 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 parcelingscheme 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 tothe 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. 1. Endos must have exactly one vertical spine.  The Medium variant spine must be at a 1:2 horizontal offset from the centerline of thedevice 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 endoconfgurationsfor 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 foreach endo size variant. Figure shows the valid set of front endo configurations for
17 each sizevariant, labeled A through L. Front modules for the Largeendo variant will be formalized in afuture MDK release. Figure 7.2.1 front parceling schemes
18 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 endooptimizes 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.
19 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.
20 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 UniPro 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.
21 9. EXTENDED ARCHITECTURE The envelope for a module comprises the standard dimensions for the module to conform to the Araendos. 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
22 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
23 Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance
24 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
25 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.
26 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.
27 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.
28 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.
29 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.
30 14. CONCLUSION  One field that is benefitting from this project is 3Dprinting  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 ofmodules 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
31 15. BIBILIOGRAPHY 1. PHONEBLOKS. Phonebloks, a phone worth keeping.2014. https://phonebloks.com/en 2. REISINGER, Don. Report: Google acquires Modu'smobile 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 MagicCube. 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 ProjectAra 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

More Related Content

14 575

  • 1. 1 A seminar report on PROJECT ARA (Modular Phones) BY K.V.G.SATISH 14A81A0575 (Under the guidance of MR.J.VIJITHANAND, M.TECH) DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING SRI VASAVI ENGINEERING COLLEGE Pedatadepalli, Tadepalligudem-534101, W.G.Dist, AndhraPradesh, 2016 - 17
  • 2. 2 INDEX Content Name Page No. 1. Introduction 1 2. Project ara an overview 3 3. General Hardware Architecture 4 4. Design Language 6 4.1 Design Language – Specification 6 5. Module Geometry and Assemblies 8 6. Electro-Permanent Magnets (Epm) 10 7. Parceling Schemes 12 7.1 Rear Parceling Scheme 12 7.2 Front Parceling Scheme 12 8. Power Architecture 14 8.1 Power Consumer Module 15 8.2 Charger Module 16 8.3 Power Storage Module 16 9. Extended Architecture 17 10. Software Architecture 20 10.1 Kernel Drivers 21 10.2 Android Hals 21 10.3 Android Application 21 11. System-Level Functions 22 11.1 Module Detect 22 11.2 Enumeration 22 11.3 Epm Control 23 11.4 Active Thermal Management 23 12. Advantages 24 13. Disadvantages 25 14. Conclusion 26 15. Bibliography 27
  • 3. 3 LIST OF FIGURES Figure Name Page No. Figure 1.1 Project Ara 2 Figure 3.1: Ara Endo (Medium Variant) 4 Figure 5.1 -Rear Modules 8 Figure 5.2 Rear Module Sub-assemblies(1x2 module) 9 Figure 6.1 - Rear Module EPM Exploded View 10 Figure 7.2.1 front parceling schemes 13 Figure 8.1 -Power Architecture 15 Figure 9.1 - Pulse Oximeter Module with Y-Dimension Exceedance 18 Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance 19 Figure 10.1 - Software Architecture 20
  • 4. 4 ABSTRACT Project Ara is the codename for an unnamed modular smartphone that is essentially a computer board with compatible modules. The platform will include a endoskeletal frame with modules of the owner's choice, such as a display, camera or an extra battery. The phone itself can be swapped from malfunctioning modules or upgrades as innovations emerge, providing longer handset cycle lifetime, and potentially reducing electronic waste. ProjectAra smartphone is scheduled to release a developer version in the United States in the fourth quarter of 2016 with a target bill of materials cost of $50 for a basic grey phone.A consumer version is not expected until at least 2017. The project was originally headed by the Advanced Technology and Projects team within Motorola Mobility while it was a Google subsidiary. Although Google has since divested Motorola to Lenovo, it retained the ATAP group, now a division under Android.The project separated from ATAP and is now an independent division.
  • 5. 5 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’ssuccess 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.
  • 7. 7 5. PROJECTARAANOVERVIEW 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.
  • 8. 8 6. GENERAL HARDWARE ARCHITECTURE Figure 3.1: Ara Endo (Medium Variant) 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
  • 9. 9 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 endosslots, which hasa 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 Arafulfillment Process. Table 3.1– Terms and definitions.32
  • 10. 10 4. DESIGN LANGUAGE The design language is a set of design elements used to visually communicate a specificaesthetic. Implementing a consistent design language ensures that every Ara phone has a set of aesthetically cohesive modules, even though each phone may include modules fromdifferent 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 tounderstand 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 ina 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.
  • 11. 11 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
  • 12. 12 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.
  • 13. 13 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
  • 14. 14 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
  • 15. 15 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.
  • 16. 16 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 parcelingscheme 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 tothe 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. 1. Endos must have exactly one vertical spine.  The Medium variant spine must be at a 1:2 horizontal offset from the centerline of thedevice 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 endoconfgurationsfor 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 foreach endo size variant. Figure shows the valid set of front endo configurations for
  • 17. 17 each sizevariant, labeled A through L. Front modules for the Largeendo variant will be formalized in afuture MDK release. Figure 7.2.1 front parceling schemes
  • 18. 18 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 endooptimizes 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.
  • 19. 19 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.
  • 20. 20 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 UniPro 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.
  • 21. 21 9. EXTENDED ARCHITECTURE The envelope for a module comprises the standard dimensions for the module to conform to the Araendos. 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
  • 22. 22 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
  • 23. 23 Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance
  • 24. 24 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
  • 25. 25 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.
  • 26. 26 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.
  • 27. 27 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.
  • 28. 28 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.
  • 29. 29 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.
  • 30. 30 14. CONCLUSION  One field that is benefitting from this project is 3Dprinting  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 ofmodules 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
  • 31. 31 15. BIBILIOGRAPHY 1. PHONEBLOKS. Phonebloks, a phone worth keeping.2014. https://phonebloks.com/en 2. REISINGER, Don. Report: Google acquires Modu'smobile 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 MagicCube. 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 ProjectAra 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