Monday, March 19, 2012

PDLC Diagram

Remember the above diagram and any company follows the above steps to develop a product
Start working on each step and google to know what are the activities are performed in each step of the above
Posted by at No comments:
Labels:

Understand broad concept o product development

supplementary

Requirements for an efficient NPI process

The phases of the NPI process

The New Product Introduction process consists of the all the work involved in developing, prototyping and manufacturing a product to be introduced as an organisation’s new product for a market-place. There are generally four phases: Concept design; Physical design; Prototype manufacture; Pre-production and volume ramp. After this, the product will be handed over to full production, and the organisation may also have some involvement in after-sales.

Phase 1 – Concept design

A concept is a description of the features, form and function of a product and is usually accompanied by a set of specifications, analysis of competitive products and economic justification of the project.
Determination of customer requirements. This will be interlaced with the marketing functions that will establish whether the market exists, collect customer needs and identify lead users.
Product Design Specification. The development team will identify and benchmark competitive products and provide functional requirements and technical specifications. Plans for product options and extended product families will be developed.
Design analysis. Initially, concept development and technology assessment will take place considering product platform and architecture. Alternative concepts will be investigated and experimental prototypes built and tested. Selection of the best will take place.

Phase 2 – Physical design

Design realisation. Schematics and product layout drawings will be generated and simulations of the design will be carried out for product function, environment and any qualification to recommended regional or global safety or design standards.
Component procurement and supplier negotiations. Unit quantities would be known for bargaining power with component suppliers and designs would have to be assessed with contractors’ process capabilities.
Test strategy and process development. Manufacturing simulations would ensure the process compatibility of the manufacturing functions, both in-house and contract. Test engineers would ensure testability of the design during production.

Phase 3 – Prototype

Verification of design and process information. Prototypes should be built as close as possible to the full-scale assembly using the intended components and processes. Tooling and specialised process equipment would be designed and tested.
Conformance test and customer acceptance/demonstration products. Beta prototypes would be tested internally and used for demonstration purposes or for customer conformance and approval.

Phase 4 – Pre-production and volume ramp

Volume manufacturing qualification. Increasing product maturity levels is important for product quality and process refinement. Any final engineering changes should be actioned before large-scale manufacture. Also, the work force can be trained to use any new production processes, machines or tooling.
Evolution of manufacturing efficiencies and yields. The first process results are gathered for yield improvement studies etc.
Market and supply chain development. Market push can continue with products visible at trade fairs, customer visits etc. Regular order quantities can be placed and suppliers tested for delivery times and quantities.

Product use, product demise, disassembly and disposal

Issues to consider are:
  • distribution and field service
  • spares and repair
  • take-back, disassembly, recovery,
  • re-use, refurbishment and disposal.
[back to top]

Requirements and benefits of an efficient NPI process

It is particularly useful to consider the electronics industry because it has been under considerable pressure recently. The sales life of electronic products has decreased, prices have fallen and expectations of quality and functionality have risen. Since the 1970s, Western manufacturing in general has seen aggressive competition from traditionally subdued Far Eastern based companies. Communication technology has improved, with email and the internet, to the point that competition that was once local is now global. Here, we will explore these pressures on the electronics industry and the effect on profits. Once we understand the reasons, we can address them.
Most companies realise the importance of an efficient NPI process to develop products and get those products to the customer as quickly as possible. In the electronics industry it can mean the difference between success and failure or in extreme circumstances survival and closure. From a list of NPI efficiencies we can determine a requirements list for an NPI process to maximise profits.

The pressure on the electronics industry

The graph in Figure 1 shows the change in profit making period for various industries during the 1990s and the particular pressure on the electronics industry.

Figure 1: The change in pay-off and product life span over the 1990s

The change in pay-off and product life span over the 1990s
The product life span (PLS) is the upper line and is the length of time the product will remain on the market. The pay-off period is the lower line and is the time for the product profits to pay-off the development costs. The grey area represents clear profit. For the electronics industry the pay-off period has risen by on average 5.5% but the PLS has fallen by 46%. This has the effect of squeezing the time the products have to make profits. Also notice that the electronics industries represent the narrowest part of the graph. This means that, although other industries’ profits are being squeezed as well, there is particular pressure on the electronics industry.

Increasing profits during the NPI process

A reduction in potential profits gained requires solutions. Figure 2 is a typical product’s sales and profit cycles. The sales cycle shows no sales while the product is being developed, increase in sales on introduction to a market, steady growth of sales to a constant level during product maturity and the drop in sales during decline.

Figure 2: Profit and sales cycles for a typical product’s introduction, maturity and decline

Profit and sales cycles for a typical product’s introduction, maturity and decline
Think about the sales cycle and the rise and fall of the profit cycle. We can divide the diagram into three areas:
Product development: There are no sales therefore the profit is negative
Product introduction to the market and growth: profits increase sharply as sales rise
Maturity and decline: The sales steady and eventually decline and the profits steadily decline throughout

Increasing profits during the NPI process

Can you suggest why the profit curve is this shape and how these profits can be maximised?
Compare your answer with the discussion that follows.

Increasing profits in the electronics industry

There are three issues to consider here:

Issue 1

The first issue is the initial loss during the developmental or NPI stage (including product design, prototype manufacturing and ramp to volume production).

Figure 3: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the development phase

The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the development phase
As there are no sales of the product then the development costs provide a negative profit. To increase the clear profit made by the product further downstream, we can:
  1. Reduce the costs during the development stage (the depth of the dip). Smaller development costs will mean a faster return on investment (ROI); once the product’s sales pay off the ROI, then the product will make real profit.
  2. Reduce the development time. The shorter the development time, the sooner the product is introduced and the sooner it starts to generate returns.

Figure 4: The benefits of early introduction of a product to market

The benefits of early introduction of a product to market
Figure 4 is a graph showing the effects of introducing a product early, by shortening the development time. These are:
  1. Extension in product sales life. Products introduced earlier seldom become obsolete later. Consequently each month saved from the development cycle implies an extension to the sales period.
  2. Increased market share. The first product to the market has a 100% market share until competition catches up and releases its own. In some markets such as software and machine tools, once a system is purchased the buyer is virtually locked into the product type due to the high premium required to change.
  3. Higher profit margins. With no other competitor, a company can enjoy pricing freedom and higher margins. The price may decrease later as competitor’s products enter the market.
In contrast, Figure 4 also shows the effect of a late product introduction. The lower line shows the reduction in sales due to competition already selling similar products, and a reduction in sales life because irrespective of when a product was introduced it is likely to start to decline in sales at the same point.
Development time and cost reduction can be achieved by using tools like concurrent engineering, DfM, Value Analysis during the design phases, and Lean Manufacture and TQM during prototype manufacturing.

Issue 2

The second issue is the huge swing to a high profit on introduction of the product. The company would like to make this as high as possible and as steep as possible.

Figure 5: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the introduction and growth phases

The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the introduction and growth phases
A higher graph suggests larger profits and a steeper graph will increase the length of time the product stays at a premium market price before decline in profits occur. There are two ways to do this:
  1. Early or, if possible, first entry into the market. Again a fast development process is required – this aspect is described above.
  2. Good promotional activity of the right product. An awareness of the market and its customers is required to highlight potential market sectors for product launching. This information would be provided by marketing functions, but the development team is responsible for:
    • Ensuring the product only satisfies the requirements of the customer. Development time and cost can easily be wasted on adding unnecessary functions to a product.
    • Ensuring the developed product is of the best quality. This is a powerful product differentiator that improves a company’s reputation, sales margins, price potential and product sales life. A poor quality product can have a disastrous effect.
These both add up to ‘total customer satisfaction’. Tools such as QFD would be useful here – this is described in the next part.

Issue 3

The third is the slow decline in profit as the product matures and declines.

Figure 6: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the maturity and decline phases

Figure 6: The profit and sales cycles for a typical product’s introduction, maturity and decline, highlighting the maturity and decline phases
This is inevitable, as the price will reduce to sustain sales when the competition increases and undercuts your own prices. Reducing the manufacturing costs would maximise the profits at this stage and allow sales functions flexibility when promoting the product. Tools such as Lean Manufacturing would be helpful here.
[back to top]

A requirements list for the NPI process

We can now derive a list of requirements for an organisation’s NPI process.
Develop the right product. We must first make sure we understand the market we are introducing our products to. The marketing functions must make sure it is the right market and provide added value if we are competing with other similar products. The development team must provide correct functional specifications with any options offered to ensure the development energy is focused on the right product. They must benchmark against competitor’s products if available.
Fast development process. Once we know what the product is supposed to do we must develop that product as quickly and cheaply as possible.
A cost effective manufacturing process. If the product is cheaper to manufacture than the competitors’ products, there will be greater profit margins, a faster ROI and more scope for sales functions to undercut competitors.
Provide quality products on time, every time. The aim is to provide ‘Total Customer Satisfaction’.
For NPI to work cost-effectively, we need to use appropriate tools to increase the efficiency. What some of these tools are, and the areas where can be applied in relation to the flow chart given in Figure 7, is the subject of New Product Introduction tools.

Figure 7: Flow chart of a typical product development process

A typical product development process
[back to top]
Posted by at No comments:
Labels:

Challenge!!!!!!!!!

Can anybody suggest a good method to stop piracy??
Posted by at No comments:
Labels:

MISRA C Rules

MISRA C Rules
The following is a summary of the MISRA C rules. This document is not a definitive list these rules,
which are only and completely defined in "MISRA Guidelines for the use of the C language in
vehicle based software".
Environment
1 (req): All code shall conform to ISO 9899 standard, with no extensions permitted.
2 (adv): Code written in languages other than C should only be used if there is a defined interface
standard for object code to which the compiler/assembler for both languages conform
3 (adv): Assembler language functions that are called from C should be written as C functions
containing only in-line assembly language, and in-line assembly language should not be
embedded in normal C code
4 (adv): Provision should be made for appropriate run-time checking
Character Sets
5 (req): Only those characters and escape sequences that are defined in the IOS C standard shall be
used
6 (req): Values of character types shall be restricted to a defined and documented subset of ISO
10646-1
7 (req): Tri-graphs shall not be used
8 (req): Multibyte characters and wide string literals shall not be used
Comments
9 (req): Comments shall not be nested
10 (adv): Sections of code should not be commented out
Identifiers
11 (req): Identifiers shall not rely on the significance of more than 31 characters.
Compiler/linker shall check to ensure that 31 char significance and case sensitivity are
supported for external identifiers
12 (adv): Identifiers in different namespace shall not have the same spelling.
Structure members are an exception
Types
13 (adv): The basic types char, int, short, long, double and float should not be used. Specific-length
equivalents should be typedef’d for the specific compiler, and these names used in the code
14 (req): The type char shall always be declared as unsigned char or signed char.
See rule 13
15 (adv): Floating point implementations should comply with a defined floating point standard
16 (req): The underlying bit representation of floating point numbers shall not be used in any way
by the programmer
17 (req): typedef names shall not be reused
Constants
18 (adv): Numeric constants should be suffixed to indicate type if possible
19 (req): Octal constants shall not be used
Zero is okay
Declarations and Definitions
20 (req): All object and function identifiers shall be declared before use
21 (req): Identifiers in an inner scope shall not use the same name as an identifier in an outer scope,
and therefore hide that identifier
22 (adv): Declaration of object should be at function scope unless a wider scope is necessary
23 (adv): All declarations at file scope should be static if possible
24 (req): Identifiers shall not simultaneously have both internal and external linkage in the same
translation unit
25 (req): An identifier with an external linkage shall have exactly one external definition
26 (req): If objects are declared more than once they shall have compatible declarations
27 (adv): External objects should not be declared in more than one file
28 (adv): The register storage class specifier should not be used
29 (req): The use of a tag shall agree with its declaration
Initialisation
30 (req): All automatic variables shall have a value assigned to them before use
31 (req): Braces shall be used to indicate and match the structure in the non-zero initialisation of
arrays and structures
32 (req): In an enumerator list the = construct shall not be used to explicitly initialise members other
than the fist unless it is used to initialise all items
Operators
33 (req): The right hand operand of a && or || shall not contain side effects
34 (req): The operands of a logical && or || shall be primary expressions
A single identifier, constant or parenthesised expression
35 (req): Assignment operators shall not be used in expressions that return Boolean values
36 (adv): Logical operators shall not be confused with bitwise operators
37 (req): Bitwise operations shall not be performed on signed integer types
38 (req): The right hand operand of a shift operator shall lie between zero and one less the width in
bits of the left hand operand
39 (req): The unary minus operator shall not be applied to an unsigned expression
40 (adv): The sizeof operator should not be used on expressions that contain side effects
41 (adv): The implementation of integer division in the chosen compiler should be determined,
documented and taken into account
42 (req): The comma operator shall not be used, except in the control expression of a for loop
Conversions
43 (req): Implicit conversions that might result in a loss of information shall not be used
44 (adv): Redundant explicit cast should not be used
45 (req): Type casting from any type to or from pointers shall not be used
Expressions
46 (req): The value of an expression shall be the same under any order of evaluation that the
standard permits
47 (adv): No dependence should be placed on C’s precedence rules
48 (adv): Mixed precision arithmetic should use explicit casting to generate the desired result
49 (adv): Tests of a value against zero should be explicit, unless the operant is effectively Boolean
50 (req): Floating point variables shall not be tested for exact inequality or inequality
51 (adv): Evaluation of constant unsigned integer expression should not lead to wrap-around
Control Flow
52 (req): There shall be no unreachable code
53 (req): All non-null statements shall have a side effect
54 (req): A null statement shall only appear on a line by its self, and shall not have any other text on
the same line
55 (adv): Label should not be used except in switch statements
56 (req): The goto statement shall not be used
57 (req): The continue statement shall not be used
58 (req): The break statement shall not be used, except to terminate the cases of a switch statement
59 (req): The statements forming the body of an if, else if, else, while, do … while or for statement
shall always be enclosed in braces
60 (adv): All if, else if constructs should contain a final else clause
61 (req): Every non-empty case clause in a switch statement shall be terminated with a break
statement
62 (req): All switch statements shall contain a final default clause
63 (adv): A switch expression should not represent a Boolean value
64 (req): Every switch statement should have at least one case
65 (req): Floating point variables shall not be used as loop counters
66 (adv): Only expression concerned with loop control should appear within a for statement
67 (adv): Numeric variables being used within a for loop for iteration counting should not be
modified in the body of the loop
Functions
68 (req): Functions shall always be declared at file scope
69 (req): Functions with a variable number of arguments shall not be used
70 (req): Functions shall not call themselves directly or indirectly
71 (req): Functions shall always have prototype declarations and the prototype shall be visible at
both the function definition and call
72 (req): For each function parameter the type given and definition shall be identical, and the return
type shall be identical
73 (req): Identifiers shall either be given for all parameters in a prototype declaration, or none
74 (req): If identifiers are given for any parameters, then the identifiers used in declaration and
definition shall be identical
75 (req): Every function shall have an explicit return type
76 (req): Functions with no parameter list shall be declared with parameter type void
77 (req): The unqualified type of parameters passed to a function shall be compatible with the
unqualified expected types defined in the function prototype
78 (req): The number of parameters passed to a function shall match the function prototype
79 (req): The value returned by void functions shall not be used
80 (req): Void expressions shall not be passed as function parameters
81 (adv): const qualification should be used on function parameters that are passed by reference,
where it is intended that the function will not modify the parameter
82 (adv): A function should have a single exit point
83 (req): For functions that do not have a void return type:
i) There shall be one return statement for every exit branch (including the end of the
program)
ii) Each return shall have an expression
iii) The return expression shall match the return type
84 (req): For functions with void return type, return statements shall not have an expression
85 (adv): Functions called with no parameters should have empty parentheses
86 (adv): If a function returns error information then that information should be tested
Pre-Processing Directives
87 (req): #include statements in a file shall only be preceded by other pre-processor directives or
comments
88 (req): Non-standard characters shall not occur in header file names in #include directives
89 (req): The #include directive shall be followed by either a of "filename" sequence
90 (req): C macros shall only be used for symbolic constants, function like macros, type qualifiers
and storage class specifiers
91 (req): Macros shall not be #define'd and #undef'd within a block
92 (adv): #undef should not be used
93 (adv): A function should be used in preference to a function-like macro
94 (req): A function-like macro shall not be 'called' without all of its arguments
95 (req): Arguments to a function-like macro shall not contain tokens that look like pre-processor
directives
96 (req): In the definition of a function-like macro the whole definition, and each instance of a
parameter, shall be enclosed in parenthesis
97 (adv): Identifiers in pre-processor directives should be defined before use
98 (req): There shall be at most one occurrence of the # or ## pre-processor operators in a single
macro definition
99 (req): All use of #pragma directive shall be documented and explained
100 (req): The defined pre-processor operator shall only be used in one of the two standard forms
Pointers and Arrays
101 (adv): Pointer arithmetic shall not be used
102 (adv): No more than 2 levels of pointer indirection should be used
103 (req): Relational operators shall not be applied to pointer types except where both operands are
of the same type and point to the same array, structure or union
104 (req): Non-constant pointers to functions shall not be used
105 (req): All functions pointed to by a single pointer to a function shall be identical in the number
and type of parameters and the return type
106 (req): The address of an object with automatic storage shall not be assigned to an object which
may persist after the object has ceased to exist
107 (req): The null pointer shall not be dereferenced
Structures and Unions
108 (req): In the specification of a structure or union type, all members of the structure or union shall
be fully specified
109 (req): Overlapping variable storage shall not be used
110 (req): Unions shall not be used to access the sub-parts of larger data types
111 (req): Bit fields shall only be defined to be one of type unsigned int or signed int
112 (req): Bit fields of type signed int shall be at least 2 bits long
113 (req): All members of a structure or union shall be named and shall only be access with their
name
Standard Libraries
114 (req): Reserved words and the standard library function names shall not be redefined or
undefined
115 (req): Standard library names shall not be reused
116 (req): All libraries used in production code shall be written to comply with the provisions of
"MISRA Guidelines for the use of the C language in vehicle based software", and shall
have been subject to appropriate validation
117 (req): The validity of values passed to library functions shall be checked
118 (req): Dynamic heap memory allocation shall not be used
119 (req): The error indicator errno shall not be used
120 (req): The macro offsetof, in library , shall not be used
121 (req): and the setlocale function shall not be used
122 (req): The setjmp macro and the longjmp function shall not be used
123 (req): The signal handling facilities of shall not be used
124 (req): The input/output library shall not be used in production code
125 (req): The library functions atof, atoi and atol from library shall not be used
126 (req): The library functions abort, exit, getenv and system from library shall not be
used
127 (req): The time handling functions of library shall not be used
Posted by at 1 comment:
Labels:

C Sample questions

Drives you
to Industry
PROGRAMMING LANGUAGE ‘C’
1. main()
{
int a=4,b=2;
a=b<>2;
}
{
}
{
}
{
}
{
}
{
2
}
}
}
{
}
{
}
{
}
{
}
}
{
}
{
}
{
}
{
}
{
}
{
{
}
{
}
{
}
{
}
{
}
5
{
}
6
7
8
9
Posted by at 20 comments:
Labels:

Important questions

1. What is linker , input files to linker
2. What is interrupt
3. difference between interrupt and function
4. Can we define the variable storage location?
5. what is multiplexer speed
6. design an surviellance system
7. can multiplexer o/p can be i/p
8. SPI
9. Synchronous and asynchronous communication
10. what do you minimize runtime
11.do you use nested interrupts
12. How do u design stack
13. what is stored in stack
14. control the automobile headlights schematics
15. types of motors
16. types of dc motors
17. which sensors you used in project
18. what is PWM
19.do while syntax
20. While syntax
21. interrupt syntax
22. types of interrupts
23.compiler
24.can we control variable storage
25. what is negative and positive testing
26. different types of models waterfall/spiral/v&v
27.what is ram & rom size of lpc2148
28.close loop and open loop?
Posted by at No comments:
Labels:

Saturday, September 11, 2010

Reg Basics In Embedded Interviews

Hi,
Today we will discuss on the basics of Embedded Interviews
The syllabus for preparing should be like this
1. C langauge
2. Basic Electronics
3. Communication Systems
4. Operating System concepts
Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)