Green Bike is a research project held at the University of Applied Sciences Upper Austria (FH Wels), that was aimed to develop a concept electric bike by following the development process model with reference architecture for embedded systems based on the Architectural blueprint for CIM Data base.You can read more at http://greenbikes.manishabraham.com/

1. PEP
Green Bikes International FSP
Presentation
Final Presentation
www.greenbikes.manishabraham.com

2. FSP Page - 2
Green Bikes International Team
Project Leader
Manish Abraham
Engineering Manager
Muna Abdulrahman
Design Engineer
Abraham De Ochoa
Design Engineer
Mahdi Baghban Pourasl
Systems Manager
Haydee Capco
Nina Asadi Moghadas
Systems Engineer
Cristian Gidea
Systems Engineer
Shakh Alauddin

3. FSP
The Flow of the Presentation
Page - 3

4. FSP Page - 4
The Flow of the Presentation

5. FSP
Development process
(Conceptual design)
Page - 5

6. FSP
Overall Project Plan
Page - 6

7. FSP
Stakeholder Requirements
Page - 7
The E-bike shall be profitable after 100 units.
The E-bike shall be made of at least 50% recycled
materials.
The E-bike shall run for at least 60 km on a full
charge.
The E-bike should be energy-autonomous.

8. FSP
Stakeholder Requirements
The E-bike should be able to last at least 800
charge cycles.
The E-bike's initial aesthetic design shall have at
least a 50% approval rate from a focus group.
The E-bike should be a silent bike.
The E-bike should bring about a young and sporty
feeling for the user.
Page - 8

9. FSP
Initial Design Concepts
Page - 9

10. FSP
Conceptual Design
Page - 10

11. FSP
Development Process
for the Conceptual
Design
Page - 11

12. FSP
Conceptual Data Model
Page - 12

13. FSP
Nomenclature
Naming convention of system elements
All files/entry names were named starting with “GB”
followed by the element name
All the levels were defined with “L”, numbered and
separated with “_“.
E.g. GB_FC_L1.... (with levels)
Page - 13

14. FSP Page - 14
Functions GB_FC_
System Definition GB_SD
Stakeholder Requirements GB_SH _
System Requirements GB_SR_
Requirements Set GB_RS_
Derived Requirements GB_DR_
System Definition GB_SD_
SD Procedure GB_PROC_
SD Physical GB_PHY
SD Hardware GB_HW
SD Software GB_SW
SD Interface GB_IF
Baseline Functions GB_BL_FC
Nomenclature

15. FSP
Functions GB_FC_
Baseline SD Ordinal GB_BL_OD
Baselines Documents GB_BL_DOC
Baseline Parts GB_BL_PAR
Baseline Hardware GB_BL_HW
Baseline Software GB_BL_SW
Baseline Collector GB_BL_COLLECTOR
Part Master Parts GB_PAR
CAD Files GB_CAD_
Project Management GB_PM_
Derived Requirements GB_DR_
PDF Files GB_PDF_
Office Document File GB_DOX_
Page - 15
Nomenclature

16. FSP
System Engineering
Functional Decomposition
Requirements Definition
System Breakdown
Generic breakdown of the product from a system point of view.
Decomposition of the product with no specific solution in mind
Physical Interfaces
General Guidelines
Needs to be consistent with defined functions and
requirements
Follow consistent nomenclature rules
Review and release items
Page - 16

17. FSP
Functional Decomposition
Page - 17

18. FSP Page - 18
Creating Functions and
Defining Functional Structure

19. FSP
Requirements Definition
Page - 19
Functional Breakdown
Physical Requirements
Requirement Management
Stakeholders
Requirements
Functional
Breakdown
System
Requirement
Derived
Requirements

20. FSP Page - 20
System Requirements
Inside CIM db

21. FSP
Requirements Set:
Page - 21

22. FSP Page - 22
Linking Functions to
Requirements

23. FSP
System Breakdown
Page - 23

24. FSP
System Definition
(inside CIM Database)
Objects
System Definition Ordinal
System Definition Procedure
System Definition Physical
System Definition Hardware
System Definition Software
System Definition Interfaces
Information
Nomenclature, Acronym, Description
Project, Maturity, other descriptions
Page - 24

25. FSP
System Definition Ordinal
Each system element is created and defined in CIM
database.
This will be the foundation for the detailed structured
view of the system.
Top level generic nomenclature and information.
Clear illustration and representation of the system
Gives the user a complete overview of the system for
assessment and review.
Page - 25

26. FSP
System Definition Ordinal
Tasks
SD-00000 - Data Sheet
–Enter information of each system element into
its own SD datasheet in CIM database
SD-00001 – SD Structure Ordinal
–System Architecture- Define/Link relationships
and levels of the system
–Father-child relationships
–Top-down Structure
Page - 26

27. FSP
System Definition Ordinal
Tasks
SD-00001 - System Definition to Requirement Set
–Link to system requirement sets
SD-00001 - Files
–Link files
–For easy access to related and relevant files
Page - 27

28. FSP
System Definition Procedure
Collector of documents
Rules, standards, generic documents which are usually not
directly related to the product
For convenient reference
Task
Create SD Procedure entries and upload related files
Revisioning (Indexing/Issues)
Result
SD Procedures - SDPR-00002
Page - 28

29. FSP
System Definition Physical
Abstract definition of the physical components
Provides the engineering department a system
definition view of physical parts as reference when
defining or creating specific parts
Task
Create general non-specific physical components of the
system in CIM database
Link to (specific) parts
Result
SD Parts
Page - 29

30. FSP
System Definition Physical
(example)
Page - 30
Reference in CIM database: SD physical---right click on item---SD physical to Part

31. FSP
System Definition Hardware
Refers exclusively to all computer hardware related to
the system (product).
Task
Create and define SD Hardware entries in the database
Result
SD Hardware
Page - 31

32. FSP
System Definition Software
Refers exclusively to all computer software related to
the system (product).
Task
Create and define SD Software entries in the
database
Result
SD Software
Page - 32

33. FSP
System Definition Interfaces
Defines horizontal relationships between system and
gives the user a clear view of physical interfaces from
a system view.
Task
Create and define Interfaces
Interfaces between systems
Result
SD Interfaces
Page - 33

34. FSP Page - 34
Physical Interface of Parts

35. FSP
System Definition Ordinal
Relationships
Tasks
SD-00000 - SD Ordinal to SD Procedure
–Link system elements to related SD Procedure
SD-00001 - SD Ordinal to SD Physical
–Link system elements to related SD Physical
elements
Page - 35

36. FSP
System Definition Ordinal
Relationships
Tasks
SD-00008 - SD Ordinal to SD Hardware
–Link system elements to SD Hardware of the
system
SD-00008 - SD Ordinal to SD Software
–Link system elements to SD Software of the
system
Page - 36

37. FSP
System Engineering
Generating the Structure View
Integration of all information entered into the database
Structured view of the whole system
View all links and relationships with one click
Page - 37

38. FSP Page - 38
Structure View Result
SD-00000 - System Definition -
System definition all relationships
SD-00002/1
SDPH-000063/1

39. FSP
Bill of Materials
Two types:
Engineering Bill Of Materials (E-BOM)
Manufacturing Bill Of Materials (M-BOM)
The E-BOM and M-BOM contain the product knowledge
of how to build and how to manufacture a product. They
are presented as assembly trees that represent a
hierarchical structure for the assemblies, subassemblies
and parts that make up the product, whether purchased
or manufactured.
Page - 39

40. FSP
E-BOM vs. M-BOM
E-BOM
Defines and manages the components and structure of the product
being manufactured.
Contains the list of items, parts, components, sub-assemblies and
assemblies in the product designed by engineering.
Represents only the physical product being “engineered,” not the
packaging or manufacturing consumables.
M-BOM
Contains details of the parts and assemblies required to build a
complete and shippable product. (eg: Kits, Structures, Assembly
processes…etc.).
Reflects the manufacturing process, represents physical product,
packaging and included documentation (CAD files, PDF,…etc.).
Page - 40

41. FSP
E-BOM vs. M-BOM example 1
Page - 41
Product
Component B1
Component B2
Component C
Component D
Product
Component B1
Component B2
Component C
Assembly A
(E-BOM) (M-BOM)

42. FSP
E-BOM vs. M-BOM example
1.1
Page - 42
Part Number Part Name
000045 Head Tube
000046 Handle Bar
000049 Phone Holder
... …

43. FSP
Why is it important to have
the two views?
Page - 43
E-BOM M-BOM
Supports better purchasing decisions,
manufacturing process and logistics
choices
The information from the M-BOM feeds
the business systems used to order
parts and build the product
Extra and unnecessary changes in the
manufacturing process can be avoided
Supports the successful management of
manufacturing resources
Disruptive last minute changes can be
avoided with an accurate E-BOM
because all the details including parts,
items, components and quantities are
correctly noted.
Enables the final transition from
product concept to a concrete,
touchable object
Smoother hand-off to manufacturing Saves time in assembly process

44. FSP Page - 44
Conceptual Design E-BOM and
E-BOM
E
-
B
O
M
M
-
B
O
M

45. FSP
Parts and BOM’s in CIM-
Database
Page - 45

46. FSP
Parts and BOM’s in CIM
Database cont.
Page - 46
Part
Number
Part Name
000007 Rim
000061 Tire
000014 Spokes
000015 Valve
Reference in CIM database: Part Master---Double click on the part---select BOM tab in the pop up menu

47. FSP
Linking Parts to CAD documents
Page - 47

48. FSP
Short Assembly Video
Page - 48

49. FSP
Baselines
Page - 49
A snapshot of system defining objects at a certain
point in time.
A stable reference for future work.
Captured state of the project for use in assessing
and analyzing the system and its components.

50. FSP Page - 50
Baseline Master
Collects created
baselines to capture
progress points within
the system
development life cycle.
For convenient
reference and
traceability
Baseline Master (Collector)
Baseline SD Ordinal
Baseline Functions
Baseline Documents
Baseline SD Physical
Baseline Hardware
Baseline Software

51. FSP
SD Structure
Ordinal
Functions
System Engineering
Relationships (CIM Database)
Page - 51
Stakeholders
Requirements
System
Requirements Derived
Requirements
SD
Procedures
SD
Interfaces
SD Software
SD
Hardware
SD Physical
M-Bom
E-Bom
Requirement
Set
SD Ordinal
Baseline
Collector
Functional
Structure
Functions
SD Structure
Ordinal
Files
Parts
Baseline
Documents
Baseline
SD Ordinal
Baseline
Functions
Baseline
Hardware Baseline
Software
Baseline
SD Physical

52. FSP
Manageability of all product-related documents and
files
Accessibility of parts, documents and changes
Traceability of product data
Change Management
Page - 52
Benefits of PLM/PDM Solutions

53. FSP
KEY EXPERIENCES
GREEN BIKES
INTERNATIONAL
Page - 53

54. Page - 54

55. FSP
Few Thoughts about the Process
Page - 55

56. Page - 56

57. FSP
Few Thoughts about team work
Page - 57

58. FSP
Few Aha Experiences
“It was surprising and interesting to learn on the way how simple
details of the product get related at some point of the process.”
“Something the system engineering is Aha experience. Because
we know but we can not remember, when someone reminds this
we remember.”
“Many things worked on Trial and Error”.
Page - 58

59. Page - 59

60. FSP Page - 60

61. FSP
Thank you for your attention!
Page - 61