22 ਅਗ 2025·8 ਮਿੰਟ
NXP Semiconductors: ਆਟੋਮੋਟਿਵ ਚਿਪ ਕਿਉਂ ਕਈ ਸਾਲਾਂ ਲਈ ਪੱਕੇ ਰਹਿੰਦੇ ਹਨ
ਦੇਖੋ ਕਿ ਲੰਬੇ ਡਿਜ਼ਾਈਨ ਚੱਕਰ, ਸੁਰੱਖਿਆ ਮਿਆਰ, ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕੰਮ ਕਿਵੇਂ NXP ਆਟੋਮੋਟਿਵ ਅਤੇ ਐਂਬੈੱਡਡ ਚਿਪਾਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਆਣ ਤੋਂ ਬਾਅਦ ਬਦਲਣਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।
ਦੇਖੋ ਕਿ ਲੰਬੇ ਡਿਜ਼ਾਈਨ ਚੱਕਰ, ਸੁਰੱਖਿਆ ਮਿਆਰ, ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕੰਮ ਕਿਵੇਂ NXP ਆਟੋਮੋਟਿਵ ਅਤੇ ਐਂਬੈੱਡਡ ਚਿਪਾਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਆਣ ਤੋਂ ਬਾਅਦ ਬਦਲਣਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।
“ਸਟਿੱਕੀ” ਇੱਕ ਵਰਤੋਂਯੋਗ ਸ਼ਬਦ ਹੈ ਜੋ ਉਸ ਚਿਪ ਨੂੰ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਚੁਣਨ ਤੋਂ ਬਾਅਦ ਬਦਲਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਆਟੋਮੋਟਿਵ ਸੈਮੀਕੰਡਕਟਰ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਐਂਬੈੱਡਡ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਪਹਿਲੀ ਚੋਣ ਸਿਰਫ਼ ਖਰੀਦ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਦੀ ਕਮਿੱਟਮੈਂਟ ਹੁੰਦੀ ਹੈ ਜੋ ਇੱਕ ਵਾਹਨ ਪ੍ਰੋਗਰਾਮ ਤੱਕ (ਅਕਸਰ ਉਸ ਤੋਂ ਵੀ ਅੱਗੇ) ਚੱਲ ਸਕਦੀ ਹੈ।
ਇੱਕ ਚਿਪ ਉਸ ਵੇਲੇ ਸਟਿੱਕੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਉਹ “designed in” ਹੋ ਜਾਵੇ। ਇੰਜੀਨੀਅਰ ਉਸਨੂੰ ਪਾਵਰ ਰੇਲ, ਸੈਂਸਰ, ਮੈਮੋਰੀ ਅਤੇ ਕਮਿਊਨੀਕੇਸ਼ਨ ਨਾਲ ਜੋੜਦੇ ਹਨ; ਫਰਮਵੇਅਰ ਲਿਖਦੇ ਅਤੇ ਵੈਧ ਕਰਦੇ ਹਨ; ਟਾਈਮਿੰਗ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨ ਕਰਦੇ ਹਨ; ਅਤੇ ਪੂਰੇ ECU (ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਅਤੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਕੰਪੋਨੈਂਟ) ਦੀ ਪੇਸ਼ਿੰਦਾ ਵਿਵਹਾਰਕਤਾ ਦਾ ਪ੍ਰਮਾਣ ਦੇਂਦੇ ਹਨ। ਇਸ ਨਿਵੇਸ਼ ਤੋਂ ਬਾਅਦ, ਸਿਲਿਕਾਨ ਨੂੰ ਬਦਲਣਾ ਸਪ੍ਰੈਡਸ਼ੀਟ 'ਤੇ ਪาร์ਟ ਬਦਲਣ ਵਾਂਗ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਹਾਰਡਵੇਅਰ, ਸਾਫਟਵੇਅਰ, ਸੇਫਟੀ ਦਸਤਾਵੇਜ਼, ਟੈਸਟਿੰਗ ਅਤੇ ਉਤਪਾਦਨ ਲਾਈਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ।
ਉਪਭੋਗਤਾ ਇਲੈਕਟ੍ਰਾਨਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਰੀਫਰੇਸ਼ ਸਾਈਕਲਾਂ ਅਤੇ ਢੀਲੇ ਚੇਂਜ ਕੰਟਰੋਲ ਨੂੰ ਸਹਨ ਕਰ ਲੈਂਦੀਆਂ ਹਨ। ਜੇ ਇੱਕ ਫ਼ੋਨ ਅਗਲੇ ਸਾਲ ਵੱਖਰਾ ਅੰਗ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਪੂਰੇ ਡਿਵਾਈਸ ਜਨਰੇਸ਼ਨ ਹੀ ਬਦਲ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ।
ਵਾਹਨਾਂ ਅਤੇ ਉਦਯੋਗਿਕ ਉਤਪਾਦਾਂ ਉਲਟ ਹਨ: ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਲਾਂ ਤੱਕ ਉਤਪਾਦਨ ਵਿੱਚ ਰਹਿਣ ਦੀ ਉਮੀਦ ਰਹਿੰਦੀ ਹੈ, ਸਖ਼ਤ ਹਾਲਾਤਾਂ 'ਚ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਿਸਯੋਗ ਰਹਿਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਸ ਕਰਕੇ ਲੰਬੇ ਉਤਪਾਦ ਲਾਈਫਸਾਇਕਲ ਅਤੇ ਸਪਲਾਈ ਕਮਿੱਟਮੈਂਟ ਚਿਪ ਚੋਣ ਦਾ ਕੇਂਦਰ ਬਣ ਜਾਂਦੇ ਹਨ—ਇਹੀ ਇੱਕ ਕਾਰਨ ਹੈ ਕਿ NXP Semiconductors ਵਰਗੇ ਸਪਲਾਇਰ ਇਕ ਵਾਰੀ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਹੋਣ ਤੇ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇਹ ਲੇਖ ਉਹ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਪ੍ਰੇਰਣਾਵਾਂ ਉੱਤੇ ਧਿਆਨ ਦੇਵੇਗਾ ਜੋ ਸਟਿੱਕੀਨੈਸ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਨਾਂ ਕਿ ਸਪਲਾਇਰ ਨੇਗੋਸ਼ੀਏਸ਼ਨ ਜਾਂ ਗੁਪਤ ਪ੍ਰੋਗਰਾਮ ਵੇਰਵਿਆਂ ਉੱਤੇ। ਮੁੱਖ ਉਦੇਸ਼ ਇਹ ਦਿਖਾਉਣਾ ਹੈ ਕਿ “ਸਵਿੱਚਿੰਗ ਲਾਗਤਾਂ” ਵੱਧਤਰ ਯੂਨਿਟ ਕੀਮਤ ਦੀ ਥਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ, ਜੋਖਮ ਅਤੇ ਵੈਧਤਾ ਕੋਸ਼ਿਸ਼ਾਂ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀਆਂ ਹਨ।
ਆਟੋਮੋਟਿਵ ਅਤੇ ਐਂਬੈੱਡਡ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਥੀਮ ਵਾਰ-ਵਾਰ ਆਉਂਦੇ ਹਨ: ਲੰਬੇ ਡਿਜ਼ਾਈਨ-ਇਨ ਚੱਕਰ, ਫੰਕਸ਼ਨਲ ਸੇਫਟੀ ਦੀਆਂ ਮੰਗਾਂ (ਅਕਸਰ ISO 26262 ਦੇ ਨਾਲ ਮਿਲਦੀਆਂ), ਯੋਗਤਾ ਅਤੇ ਭਰੋਸਣ-ਉਮੀਦਾਂ (ਜਿਵੇਂ AEC-Q100), ਵਿਸਤ੍ਰਿਤ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਸਾਫਟਵੇਅਰ ਪਰਿਸ਼ਇਹ ਜੋ ਮੁੜ-ਬਨਾਉਣਾ ਮਹਿੰਗਾ ਬਣਾਉਂਦੇ ਹਨ। ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ਅਸੀਂ ਹਰ ਇੱਕ ਤਾਕਤ ਨੂੰ ਵੇਖਾਂਗੇ ਕਿ ਉਹ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬੱਧ ਕਰ ਦਿੰਦੇ ਹਨ।
ਆਟੋਮੋਟਿਵ ਚਿਪ ਇਸ ਲਈ “ਸਟਿੱਕ” ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਬਦਲਾਵ ਪਸੰਦ ਨਹੀਂ—ਉਹ ਇਸ ਲਈ ਪੱਕੇ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਵਿਚਾਰ ਤੋਂ ਰੋਡ-ਰੇਡੀ ਵਾਹਨ ਤੱਕ ਦਾ ਰਸਤਾ ਕਈ ਗੇਟਾਂ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਗੇਟ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਣ ਦੀ ਲਾਗਤ ਵਧਾ ਦਿੰਦੀ ਹੈ।
ਧਾਰਨਾ ਅਤੇ ਲੋੜਾਂ: ਇੱਕ ਨਵਾਂ ECU ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਪ੍ਰਦਰਸ਼ਨ, ਪਾਵਰ, ਲਾਗਤ, ਇੰਟਰਫੇਸ (CAN/LIN/Ethernet), ਸੁਰੱਖਿਆ ਅਤੇ ਸੇਫਟੀ ਲਕਸ਼ਾਂ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ।
ਸਪਲਾਇਰ ਚੋਣ ਅਤੇ ਆਰਕੀਟੈਕਚਰ: ਸਿਲਿਕਾਨ ਦੇ ਵਿਕਲਪਾਂ ਦੀ ਇੱਕ ਛਾਂਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਥੇ NXP Semiconductors ਵਰਗੇ ਕੰਪਨੀਆਂ ਖਾਸ ਫੀਚਰ, ਟੂਲ ਸਪੋਰਟ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਉਪਲਬਧਤਾ ਤੇ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ ਹਨ।
ਪ੍ਰੋਟੋਟਾਈਪ ਬਿਲਡਸ: ਸ਼ੁਰੂਆਤੀ ਬੋਰਡ ਅਤੇ ਫਰਮਵੇਅਰ ਬਣਾਏ ਜਾਂਦੇ ਹਨ। ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ, ਪਾਵਰ ਕੰਪੋਨੈਂਟ ਅਤੇ ਨੈਟਵਰਕ ਟ੍ਰਾਂਸੀਵਰ ਇੰਟੀਗਰੇਟ ਅਤੇ ਵੈਧ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਪ੍ਰੀ-ਉਤਪਾਦਨ ਅਤੇ ਉਦਯੋਗੀਕਰਨ: ਡਿਜ਼ਾਈਨ ਨੂੰ ਮੈਨੂਫੈਕਚਰਿੰਗ, ਟੈਸਟ ਕਵਰੇਜ ਅਤੇ ਭਰੋਸਣਯੋਗਤਾ ਮਾਰਜਿਨ ਲਈ ਟਿਊਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਉਤਪਾਦਨ ਦੀ ਸ਼ੁਰੂਆਤ (SOP): ਜਦੋਂ ਵਾਹਨ ਪ੍ਰੋਗਰਾਮ ਲਾਂਚ ਹੁੰਦਾ ਹੈ, ਬਦਲਾਵ ਆਹਿਸਤਾ, ਦਸਤਾਵੇਜ਼ੀਕृत ਅਤੇ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇੱਕ design win ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਨਿਰਧਾਰਤ ਚਿਪ ਕਿਸੇ ਨਿਰਧਾਰਤ ਗਾਹਕ ਪ੍ਰੋਗਰਾਮ ਲਈ ਚੁਣ ਲਈ ਗਈ ਹੈ (ਜਿਵੇਂ ਕਿ ਇੱਕ ਵਾਹਨ ਪਲੇਟਫਾਰਮ 'ਤੇ ECU)। ਇਹ ਵਪਾਰਕ ਮੀਲਪੱਥਰ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਤਕਨੀਕੀ ਕਮਿੱਟਮੈਂਟ ਵੀ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ: ਬੋਰਡ ਉਸ ਭਾਗ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਸਾਫਟਵੇਅਰ ਉਸਦੇ ਪੈਰੀਫੇਰਲ ਦੇ ਲਈ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਵੈਧਤਾ ਸਬੂਤ ਜਮ੍ਹਾਂ ਹੋ ਜਾਂਦੇ ਹਨ। ਡਿਜ਼ਾਈਨ ਵਿਨ ਤੋਂ ਬਾਅਦ, ਬਦਲਣਾ ਅਸੰਭਵ ਨਹੀਂ—ਪਰ ਅਕਸਰ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸਧਾਰਣ ਬਦਲ ਨਹੀਂ ਹੁੰਦਾ।
ਅਮਲ ਵਿੱਚ, Tier 1 ਬਹੁਤ ਸਾਰੇ ਚਿਪ-ਸਤਹ ਦੇ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ, ਪਰ OEM ਮਿਆਰ, ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵੇਂਡਰ ਲਿਸਟਾਂ ਅਤੇ ਪਲੇਟਫਾਰਮ ਦੁਹਰਾਏ ਜਾਣ ਨਾਲ ਇਸ 'ਤੇ ਭਾਰੀ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ ਕਿ ਕੀ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਕੀ ਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕਾਰ ਪ੍ਰੋਗਰਾਮ ਉਪਭੋਗਤਾ ਇਲੈਕਟ੍ਰਾਨਿਕਸ ਦੀ ਦੌੜ ਤੇ ਨਹੀਂ ਚਲਦੇ। ਇੱਕ ਵਾਹਨ ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਸਾਲਾਂ ਵਿੱਚ ਯੋਜਨਾ, ਇੰਜੀਨੀਅਰਿੰਗ, ਵੈਧਤਾ ਅਤੇ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਫਿਰ ਇਹ ਵਧੇਰੇ ਸਾਲਾਂ ਲਈ ਵਿਕਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਲੰਬੇ ਦਰਮਿਆਨ ਨੇ ਟੀਮਾਂ ਨੂੰ ਉਹ ਕੰਪੋਨੈਂਟ ਚੁਣਨ ਲਈ ਧਕਿਆ ਜੋ ਪੂਰੇ ਪਲੇਟਫਾਰਮ ਜੀਵਨ ਲਈ ਸਹਾਰਿਆ ਜਾ ਸਕੇ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪਹਿਲੀ ਉਤਪਾਦਨ ਦੌੜ ਲਈ।
ਜੇ ਇੱਕ ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਚੁਣਿਆ ਅਤੇ ਪਰਖਿਆ ਜਾ ਚੁੱਕਾ ਹੋਵੇ, ਤਾਂ ਅਕਸਰ ਇਸਨੂੰ ਰੱਖਣਾ ਸਸਤਾ ਅਤੇ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਨਾਂ ਕਿ ਫਿਰੋਂ-ਫਿਰੋਂ ਫੈਸਲਾ ਖੋਲ੍ਹਣਾ।
ਇੱਕ “ਪਲੇਟਫਾਰਮ” ਇੱਕ ਇਕੱਲਾ ਕਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਉਹੀ ਆਧਾਰਭੂਤ ਇਲੈਕਟ੍ਰਾਨਿਕਸ ਆਰਕੀਟੈਕਚਰ ਕਈ ਟਰਿਮ, ਬੋਡੀ ਸਟਾਈਲ ਅਤੇ ਮਾਡਲ ਸਾਲਾਂ ਵਿੱਚ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਈ ਵਾਰੀ ਇੱਕ ਗਰੁੱਪ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਬ੍ਰੈਂਡਾਂ ਨੂੰ ਵੀ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਦੁਹਰਾਓ ਜਾਣਬੂਝ ਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਜੇ ਇੱਕ ਚਿਪ ਉੱਚ-ਵਾਲੀਅਮ ECU ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਕਈ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਨਕਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਗੁਣਾ ਪ੍ਰਭਾਵ ਬਾਅਦ ਵਿੱਚ ਬਦਲਾਅ ਨੂੰ ਬਹੁਤ ਜਿਆਦਾ ਵਿਘਟਿਤ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਦੇ ਅੰਤ ਵਿੱਚ ਬਦਲਣਾ ਸਿਰਫ਼ ਹਿੱਸਾ ਬਦਲਣਾ ਨਹੀਂ ਹੁੰਦਾ। ਭਾਵੇਂ ਨਵਾਂ ਸਿਲਿਕਾਨ “ਪਿਨ-ਕੰਪੈਟਿਬਲ” ਹੋਵੇ, ਟੀਮਾਂ ਨੂੰ ਫਰਕ ਕੰਮ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ:
ਇਹ ਕਦਮ ਨਿਰਧਾਰਤ ਗੇਟਾਂ (ਬਿਲਡ ਇਵੈਂਟ, ਸਪਲਾਇਰ ਟੂਲਿੰਗ, ਹੋਮੋਲੋਗੇਸ਼ਨ ਡੈਡਲਾਈਨ) ਨਾਲ ਟਕਰਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਦੇਰ ਨਾਲ ਹੋਣ ਵਾਲਾ ਬਦਲਾਅ ਸ਼ੈਡਿਊਲ ਸੁਧਾਰ ਜਾਂ ਸਮਕਾਲੀ ਵਰਜਨਾਂ ਨੂੰ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ।
ਵਾਹਨਾਂ ਨੂੰ ਸਾਲਾਂ ਤੱਕ ਮੁਰੰਮਤਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। OEMs ਅਤੇ Tier 1s ਨੂੰ ਸਰਵਿਸ ਪਾਰਟਸ, ਵਾਰੰਟੀ ਮੁਰੰਮਤਾਂ, ਅਤੇ ਬਦਲੀ ECU ਲਈ ਕਨਟੀਨਿਊਟੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਮੂਲ ਵਿਹਾਰ ਨੂੰ ਮਿਲਦੀ ਹੋਵੇ। ਇੱਕ ਸਥਿਰ ਚਿਪ ਪਲੇਟਫਾਰਮ ਸਪੇਅਰ ਸਟਾਕ, ਵਰਕਸ਼ਾਪ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਹਾਇਤਾ ਨੂੰ ਸਹਲ ਕਰਦਾ ਹੈ—ਇਹ ਇੱਕ ਹੋਰ ਕਾਰਨ ਹੈ ਕਿ ਆਟੋਮੋਟਿਵ ਸੈਮੀਕੰਡਕਟਰ ਇੱਕ ਵਾਰੀ ਮਨਜ਼ੂਰ ਹੋ ਜਾਣ ਤੇ ਕਈ ਸਾਲਾਂ ਲਈ ਰਹਿ ਜਾਂਦੇ ਹਨ।
ਫੰਕਸ਼ਨਲ ਸੇਫਟੀ, ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਕਿਸੇ ਸਿਸਟਮ ਦੀ ਖ਼ਰਾਬੀ ਕਰਕੇ ਨੁਕਸਾਨ ਹੋਣ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਇਆ ਜਾਵੇ। ਇੱਕ ਕਾਰ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਦੀ ਖ਼ਰਾਬੀ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਤੇਜ਼ੀ, ਸਟੀਅਰਿੰਗ ਸਹਾਇਤਾ ਦੀ ਖ਼ਰਾਬੀ ਜਾਂ ਏਅਰਬੈਗ ਦੀ ਨਹੀ ਫਾਇਲ ਹੋਣ ਵਰਗੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਜਨਮ ਨਾ ਦੇਵੇ।
ਆਟੋਮੋਟਿਵ ਇਲੈਕਟ੍ਰਾਨਿਕਸ ਲਈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ISO 26262 ਦੇ ਤਹਿਤ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਟੈਂਡਰਡ ਸਿਰਫ਼ ਟੀਮਾਂ ਨੂੰ “ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉ” ਨਹੀਂ ਆਖਦਾ—ਇਹ ਮੰਗਦਾ ਹੈ ਕਿ ਜੋਖਮਾਂ ਦੀ ਪਛਾਣ, ਘਟਾਉਣ, вੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਸਮੇਂ-ਸਾਥ ਨਿਯੰਤਰਿਤ ਕਰਨ ਬਾਰੇ ਸਬੂਤ ਦੇ ਕੇ ਦਿਖਾਇਆ ਜਾਵੇ।
ਸੇਫਟੀ ਕੰਮ ਜਾਣ-ਬੂਝ ਕੇ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਟਰੇਲ ਬਣਾਉਂਦਾ ਹੈ। ਲੋੜਾਂ ਦਸਤਾਵੇਜ਼ੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ, ਡਿਜ਼ਾਇਨ ਫੈਸਲਿਆਂ ਨਾਲ ਜੋੜੀਆਂ ਜਾਣੀਆਂ, ਫਿਰ ਟੈਸਟਾਂ ਨਾਲ ਜੋੜੀਆਂ ਅਤੇ ਖ਼ਤਰਨਾਕ ਸਥਿਤੀਆਂ ਅਤੇ ਸੇਫਟੀ ਲਕਸ਼ਾਂ ਨਾਲ ਵਾਪਸ ਲਿੰਕ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਹ ਟਰੇਸਬਿਲਟੀ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਜਦ ਕੁਝ ਗਲਤ ਹੋਵੇ (ਜਾਂ ਜਦ ਇੱਕ ਆਡੀਟਰ ਪੁੱਛੇ), ਤੁਹਾਨੂੰ ਠੀਕ ਦਿਖਾਉਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕੀ ਨਿਸ਼ਚਿਤ ਸੀ ਅਤੇ ਕੀ ਸਾਬਤ ਕੀਤਾ ਗਿਆ।
ਟੈਸਟਿੰਗ ਦਾ ਦਾਇਰਾ ਵੀ ਵੱਧਦਾ ਹੈ। ਸਵਾਲ ਹੁੰਦਾ ਹੈ ਕਿ “ਕੀ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ” ਦੇ ਨਾਲ-ਨਾਲ “ਜੇ ਇਹ ਫੇਲ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ”, “ਜੇ ਸੈਂਸਰ ਗਲਤ ਪੜ੍ਹੇ ਤਾਂ ਕੀ ਹੋਵੇ” ਅਤੇ “ਜੇ MCU ਘੜੀ ਡ੍ਰਿਫਟ ਕਰ ਜਾਵੇ ਤਾਂ ਕੀ ਹਾਲਤ ਹੋਵੇ”। ਇਸਦਾ ਮਤਲਬ ਹੈ ਵਧੇਰੇ ਟੈਸਟ ਕੇਸ, ਵੱਧ ਕਵਰੇਜ ਉਮੀਦਾਂ, ਅਤੇ ਹੋਰ ਦਰਜ ਕੀਤੇ ਨਤੀਜੇ ਜੋ ਸ਼ਿਪ ਕੀਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਸੰਗਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ safety concept ਇਹ ਯੋਜਨਾ ਹੈ ਕਿ ਸਿਸਟਮ ਕਿਵੇਂ ਸੁਰੱਖਿਆ ਬਣਾਈ ਰੱਖੇਗਾ—ਕਿਹੜੇ ਸੇਫਟੀ ਮਕੈਨਿਜ਼ਮ ਹਨ, ਕਿਥੇ ਰਿਡੰਡੰਸੀ ਵਰਤੀ ਗਈ ਹੈ, ਕਿਹੜੇ ਡਾਇਗਨੋਸਟਿਕਸ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਫੌਲਟ ਆਉਣ 'ਤੇ ਸਿਸਟਮ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰੇਗਾ।
ਇੱਕ safety case ਉਹ ਢਾਂਚੇਵਾਰ ਦਲੀਲ ਹੈ ਕਿ ਯੋਜਨਾ ਸਹੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕੀਤੀ ਗਈ ਅਤੇ ਵੈਧ ਕੀਤੀ ਗਈ। ਇਹ ਦਲੀਲ ਅਤੇ ਸਬੂਤਾਂ ਦਾ ਬੰਡਲ ਹੁੰਦਾ ਹੈ—ਦਸਤਾਵੇਜ਼, ਵਿਸ਼ਲੇਸ਼ਣ, ਟੈਸਟ ਰਿਪੋਰਟ—ਜੋ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ “ਇਹ ECU ਆਪਣੇ ਸੇਫਟੀ ਲਕਸ਼ਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।”
ਜਦੋਂ ਇੱਕ ਚਿਪ ਚੁਣ ਲਈ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੇਫਟੀ ਕਾਂਸੈਪਟ ਅਕਸਰ ਉਸ ਖਾਸ ਸਿਲਿਕਾਨ ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ: watchdogs, lockstep ਕੋਰ, ਮੈਮੋਰੀ ਪ੍ਰੋਟੈਕਸ਼ਨ, ਡਾਇਗਨੋਸਟਿਕ ਫੀਚਰ ਅਤੇ ਵੇਂਡਰ ਸੁਰੱਖਿਆ ਮੈਨੂਅਲ।
ਜੇ ਤੁਸੀਂ ਕੰਪੋਨੈਂਟ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਪਾਰਟ ਨੰਬਰ ਨਹੀਂ ਬਦਲਦੇ। ਤੁਹਾਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੁਬਾਰਾ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਟਰੇਸਬਿਲਟੀ ਲਿੰਕ ਅਪਡੇਟ ਕਰਨੇ ਪੈਂਦੇ ਹਨ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੇ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ-ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਸੇਫਟੀ ਕੇਸ ਨੂੰ ਫਿਰ ਤਿਆਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਉਹ ਸਮਾਂ, ਲਾਗਤ, ਅਤੇ ਸਰਟੀਫਿਕੇਸ਼ਨ ਜੋਖਮ ਆਟੋਮੋਟਿਵ ਸੈਮੀਕੰਡਕਟਰਾਂ ਨੂੰ ਕਈ ਸਾਲਾਂ ਲਈ “ਸਟਿੱਕ” ਬਣਾਉਣ ਦਾ ਇੱਕ ਮੁੱਖ ਕਾਰਨ ਹੈ।
ਇੱਕ ਆਟੋਮੋਟਿਵ ਚਿਪ ਦੀ ਚੋਣ ਸਿਰਫ਼ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਕੀਮਤ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇੱਕ ਭਾਗ ਨੂੰ ਵਾਹਨ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਆਮ ਤੌਰ 'ਤੇ ਆਟੋਮੋਟਿਵ-ਯੋਗਤਾ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ—ਇੱਕ ਅਧਿਕਾਰਿਕ ਸਬੂਤ ਕਿ ਇਹ ਸਾਲਾਂ ਭਰ ਦੇ ਤਾਪਮਾਨ, ਠੰਡ, ਵਾਇਬ੍ਰੇਸ਼ਨ, ਅਤੇ ਬਿਜਲੀਕ ਤਣਾਓ 'ਚ ਹੋ ਕੇ ਵੀ ਨਿਰਧਾਰਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਰਹੇਗਾ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ AEC-Q100 (ਇੰਟੀਗਰੇਟਿਡ ਸਰਕਿਟਸ ਲਈ) ਜਾਂ AEC-Q200 (ਪੈਸਿਵ ਕੰਪੋਨੈਂਟਸ ਲਈ) ਦੀ ਸੁਣਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਟੈਸਟ ਲਿਸਟ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਪਰ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਮੰਨਿਆ ਗਿਆ ਯੋਗਤਾ ਫਰੇਮਵਰਕ ਹੈ ਜੋ ਸਪਲਾਇਰ ਉਪਕਰਨ ਨੂੰ ਆਟੋਮੋਟਿਵ ਹਾਲਾਤਾਂ ਹੇਠ ਪੇਸ਼ਬੀਨੀਯੋਗ ਵਿਹਾਰ ਦਿਖਾਉਣ ਲਈ ਵਰਤਦੇ ਹਨ।
OEMs ਅਤੇ Tier 1s ਲਈ ਇਹ ਲੇਬਲ ਇੱਕ ਗੇਟ ਹੈ। ਇੱਕ ਗੈਰ-ਯੋਗਤ ਵਿਕਲਪ ਲੈਬ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਉਤਪਾਦਨ ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਜਾਂ ਸੇਫਟੀ-ਸੰਬੰਧੀ ਪਾਵਰ ਡਿਵਾਈਸ ਲਈ ਜ਼ਿਆਦਾ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦ ਆਡੀਟ ਅਤੇ ਗਾਹਕ ਲੋੜਾਂ ਸ਼ਾਮਿਲ ਹੁੰਦੀਆਂ ਹਨ।
ਕਾਰਾਂ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਕੰਪੋਨੈਂਟ ਰੱਖਦੀਆਂ ਹਨ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਇਲੈਕਟ੍ਰਾਨਿਕਸ ਕਦੇ ਨਹੀਂ ਜਾਂਦੇ: ਇੰਜਣ ਵਾਲੀ ਥਾਂ 'ਤੇ, ਪਾਵਰਟ੍ਰੇਨ ਦੀ ਗਰਮੀ ਦੇ ਨੇੜੇ, ਜਾਂ ਸੀਲ ਕੀਤੇ ਮਾਡਿਊਲਾਂ ਵਿੱਚ ਜਿੱਥੇ ਹਵਾ-ਚਲਾਓ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਮੰਗਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦੀਆਂ ਹਨ:
ਇੱਕ ਚਿਪ ਜੇ “ਬਰਾਬਰ” ਲੱਗਦੀ ਵੀ ਹੋਵੇ, ਤਾਂ ਯੋਗਤ ਸੰਸਕਰਣ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਸਿਲਿਕਾਨ ਰਿਵਿਜ਼ਨ, ਪੈਕੇਜਿੰਗ ਜਾਂ ਮੈਨੁਫੈਕਚਰਿੰਗ ਨਿਯੰਤਰਣ ਵਰਤੇ ਗਏ ਹੋਣ ਜੋ ਉਹ ਉਮੀਦਾਂ ਪੂਰੀਆਂ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ।
ਕਿਸੇ ਚਿਪ ਨੂੰ ਦੇਰ ਨਾਲ ਬਦਲਣਾ ਮੁੜ-ਟੈਸਟਿੰਗ, ਦਸਤਾਵੇਜ਼ੀ ਅਪਡੇਟਾਂ, ਅਤੇ ਕਈ ਵਾਰ ਨਵੇਂ ਬੋਰਡ ਸਪੀਨ ਨੂੰ ਉਤਪੰਨ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਕੰਮ SOP ਤਾਰੀਖਾਂ ਨੂੰ ਦੇਰ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਨੂੰ ਹੋਰ ਮੀਲਪੱਥਰਾਂ ਤੋਂ ਦੂਰ ਖਿੱਚ ਸਕਦੇ ਹਨ।
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਾਬਤ ਹੋਏ, ਪਹਿਲਾਂ ਤੋਂ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਪਲੇਟਫਾਰਮ ਨਾਲ ਰਹਿਣ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਪ੍ਰੇਰਣਾ ਹੁੰਦੀ ਹੈ—ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਦੁਹਰਾਉਣਾ ਮਹਿੰਗਾ, ਧੀਮਾ ਅਤੇ ਸ਼ੈਡਿਊਲ-ਜੋਖਮ ਨਾਲ ਭਰਪੂਰ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ECU ਵਿੱਚ ਮਾਈਕ੍ਰोकੰਟਰੋਲਰ ਸਿਰਫ਼ "ਹਾਰਡਵੇਅਰ" ਨਹੀਂ ਰਹਿੰਦਾ। ਜਦੋਂ ਇੱਕ ਟੀਮ ਕਿਸੇ ਖਾਸ MCU ਪਰਿਵਾਰ ਨੂੰ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਲਾਉਂਦੀ ਹੈ, ਉਹ ਇੱਕ ਪੂਰੀ ਸਾਫਟਵੇਅਰ ਵਾਤਾਵਰਣ ਨੂੰ ਵੀ ਅਪਣਾਉਂਦੀ ਹੈ ਜੋ ਉਸ ਚਿਪ ਦੇ ਪੈਰੀਫੇਰਲ, ਮੈਮੋਰੀ ਲੇਆਊਟ, ਅਤੇ ਟਾਈਮਿੰਗ ਵਿਹਾਰ ਲਈ ਫਿੱਟ ਹੁੰਦੀ ਹੈ।
ਸਧਾਰਣ ਫੰਕਸ਼ਨਾਂ—CAN/LIN ਕਮਿਊਨੀਕੇਸ਼ਨ, watchdogs, ADC ਪੜ੍ਹਾਈ, PWM ਮੋਟਰ ਕੰਟਰੋਲ—ਵੀ ਵੇਂਡਰ-ਨਿਰਧਾਰਿਤ ਡ੍ਰਾਇਵਰ ਅਤੇ ਕੰਫਿਗਰੇਸ਼ਨ ਟੂਲਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਤੱਤ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਧੀਰੇ-ਧੀਰੇ ਬੁਣੇ ਜਾਂਦੇ ਹਨ:
ਜਦੋਂ ਤੁਸੀਂ ਚਿਪ ਸਵੈਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ “ਰੀਕੰਪਾਈਲ ਤੇ ਸ਼ਿਪ” ਨਹੀਂ ਕਰਦੇ—ਤੁਸੀਂ ਪੋਰਟ ਅਤੇ ਮੁੜ-ਵੈਧਤਾ ਕਰਦੇ ਹੋ।
ਜੇ ਪ੍ਰੋਗਰਾਮ AUTOSAR (Classic ਜਾਂ Adaptive) ਵਰਤਦਾ ਹੈ, ਤਾਂ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਚੋਣ Microcontroller Abstraction Layer (MCAL), Complex Device Drivers, ਅਤੇ ਉਹ ਕੰਫਿਗਰੇਸ਼ਨ ਟੂਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਜੋ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਨੂੰ ਜੈਨਰੇਟ ਕਰਦੇ ਹਨ।
ਮਿਡਲਵੇਅਰ ਹੋਰ ਇੱਕ ਲੇਅਰ coupling ਦਾ ਜੋੜਦਾ ਹੈ: ਹਾਰਡਵੇਅਰ ਸੁਰੱਖਿਆ ਮੋਡੀਊਲਾਂ ਨਾਲ ਜੁੜੇ ਕ੍ਰਿਪਟੋ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਖਾਸ ਫਲੈਸ਼ ਆਰਕੀਟੈਕਚਰ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਬੂਟਲੋਡਰ, ਕੋਰ ਲਈ ਟਿਊਨ ਕੀਤੇ RTOS ਪੋਰਟ, ਅਤੇ ਇਹੋ-ਜਿਹੇ ਡਾਇਗਨੋਸਟਿਕ ਸਟੈਕ। ਹਰ ਇੱਕ ਡਿਪੇਂਡੈਂਸੀ ਦਾ ਆਪਣੇ-ਆਪਣੇ ਸਮਾਨ ਸਹਾਇਤ ਚਿੱਟੇ ਹੋ ਸਕਦੇ ਹਨ—ਅਤੇ ਬਦਲਣ ਨਾਲ ਵੇਂਡਰਾਂ ਨਾਲ ਨਵੀਨਤਾ, ਨਵੇਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕੰਮ, ਅਤੇ ਲਾਇਸੈਂਸਿੰਗ ਜਾਂ ਵੈਧਤਾ ਕਦਮ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦੇ ਹਨ।
ਆਟੋਮੋਟਿਵ ਪ੍ਰੋਗਰਾਮ ਸਾਲਾਂ ਤੱਕ ਚਲਦੇ ਹਨ, ਇਸ ਲਈ ਟੀਮਾਂ ਉਹ ਟੂਲਚੇਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਚਾਹੁੰਦੀਆਂ ਹਨ ਜੋ ਕਾਫੀ ਸਮੇਂ ਲਈ ਸਹਾਇਤ ਰਹਿਣ। ਇੱਕ ਚਿਪ ਸਿਰਫ਼ ਤੇਜ਼ ਜਾਂ ਸਸਤਾ ਹੋਣ ਕਾਰਨ ਆਕਰਸ਼ਕ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਇਸ ਲਈ ਆਕਰਸ਼ਕ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ:
ਚਿਪ ਬਦਲਣ ਦੀ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਭਾਗ ਆਮ ਤੌਰ 'ਤੇ BOM ਸਪ੍ਰੈੱਡਸ਼ੀਟ 'ਤੇ ਨਹੀਂ ਦਿਸਦੀ:
ਲੋ-ਲੇਵਲ ਕੋਡ ਪੋਰਟਿੰਗ, ਟਾਈਮਿੰਗ ਵਿਸ਼ਲੇਸ਼ਣ ਦੁਬਾਰਾ ਕਰਨਾ, AUTOSAR ਕੰਫਿਗਰੇਸ਼ਨ ਜਨਰੇਟ ਕਰਨਾ, ਡਾਇਗਨੋਸਟਿਕ ਟੈਸਟ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰਨਾ, ਫੰਕਸ਼ਨਲ ਸੇਫਟੀ ਸਬੂਤਾਂ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣਾ, ਅਤੇ ਤਾਪਮਾਨ/ਵੋਲਟੇਜ ਕਾਰਨਾਂ 'ਤੇ ਵਿਹਾਰ ਦੀ ਵੈਧਤਾ। ਭਾਵੇਂ ਨਵਾਂ ਚਿਪ “ਕੰਪੈਟਿਬਲ” ਲੱਗੇ, ECU ਦਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪੇਸ਼ਬੀਨੀਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਉਣਾ ਸਮਾਂ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਲਾਗਤ ਮੰਗਦਾ ਹੈ—ਇਹੀ ਸਬੂਤ ਹੈ ਕਿ ਸਾਫਟਵੇਅਰ ਵਾਤਾਵਰਣ ਚਿਪ ਚੋਣ ਨੂੰ ਸਟਿੱਕੀ ਬਣਾਉਂਦੀ ਹੈ।
ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਜਾਂ ਨੈਟਵਰਕ ਟ੍ਰਾਂਸੀਵਰ ਦੀ ਚੋਣ ਸਿਰਫ਼ “ਇੱਕ ਚਿਪ” ਚੁਣਨ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇਹ ਚੁਣਨਾ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ ਬੋਰਡ ਕਿਵੇਂ ਗੱਲ ਕਰੇਗਾ, ਪਾਵਰ ਅਪ ਹੋਏਗਾ, ਡੇਟਾ ਸਟੋਰ ਕਰੇਗਾ, ਅਤੇ ਵਾਸਤਵਿਕ ਵਾਹਨ ਹਾਲਾਤਾਂ 'ਚ ਵਿਦਿਉਤ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਵਰਤਣਗਾ।
ਇੰਟਰਫੇਸ ਫੈਸਲੇ ਤਾਰਬੰਨ, ਟੋਪੋਲੋਜੀ, ਅਤੇ ਗੇਟਵੇਨ ਰਣਨੀਤੀ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। CAN ਅਤੇ LIN 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਡਿਜ਼ਾਈਨ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਇਹ ਆਟੋਮੋਟਿਵ ਈਥਰਨੈੱਟ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ, ਭਾਵੇਂ ਦੋਹਾਂ ਇੱਕੋ ਜਿਹਾ ਐਪਲੀਕੇਸ਼ਨ ਸਾਫਟਵੇਅਰ ਚਲਾ ਰਹੇ ਹੋਣ।
ਆਮ ਚੋਣਾਂ ਜਿਵੇਂ CAN, LIN, Ethernet, I2C, ਅਤੇ SPI ਵੀ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ:
ਜਦ ਇਹ ਚੋਣਾਂ ਰੂਟ ਕੀਤੀਆਂ ਅਤੇ ਵੈਧ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਕਿਸੇ ਵੱਖਰੇ ਭਾਗ 'ਤੇ ਸਵਿੱਚ ਕਰਨ ਨਾਲ BOM ਤੋਂ ਬਹੁਤ ਅੱਗੇ ਤੱਕ ਬਦਲਾਅ ਹੋ ਸਕਦਾ ਹੈ।
ਭਾਵੇਂ ਦੋ ਭਾਗ ਡੇਟਾ ਸ਼ੀਟਾਂ 'ਤੇ ਤੁਲਨਾਤਮਕ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਿਨਆਉਟ ਅਕਸਰ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦਾ। ਵੱਖ-ਵੱਖ ਪਿਨ ਫੰਕਸ਼ਨ, ਪੈਕੇਜ ਆਕਾਰ, ਅਤੇ ਬੂਟ ਸੰਰਚਨਾ ਪਿਨ PCB ਰੀ-ਲੇਆਊਟ ਨੂੰ ਮਜਬੂਰ ਕਰ ਸਕਦੇ ਹਨ।
ਪਾਵਰ ਇੱਕ ਹੋਰ ਬਿੰਦੂ ਹੈ। ਨਵਾਂ MCU ਵੱਖ-ਵੱਖ ਵੋਲਟੇਜ ਰੇਲ, ਕਸੂਤੀ ਸੀਕਵੈਂਸਿੰਗ, ਨਵੇਂ ਰੈਗੂਲੇਟਰ, ਜਾਂ ਵੱਖ-ਵੱਖ ਡੀਕਪਲਿੰਗ ਅਤੇ ਗ੍ਰਾਉਂਡਿੰਗ ਹਿੱਸਿਆਂ ਦੀ ਮੰਗ ਕਰ ਸਕਦਾ ਹੈ। ਮੈਮੋਰੀ ਦੀਆਂ ਲੋੜਾਂ ਵੀ ਤੁਹਾਨੂੰ ਇੱਕ ਪਰਿਵਾਰ 'ਤੇ ਬੰਨ੍ਹ ਸਕਦੀਆਂ ਹਨ: ਇੰਟਰਨਲ Flash/RAM ਆਕਾਰ, ਬਾਹਰੀ QSPI Flash ਸਹਿਯੋਗ, ECC ਲੋੜਾਂ, ਅਤੇ ਮੈਮੋਰੀ ਮੈਪਿੰਗ ਸਾਰਿਆਂ ਦਾ ਪ੍ਰਭਾਵ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸਟਾਰਟਅੱਪ ਵਿਹਾਰ 'ਤੇ ਪੈਂਦਾ ਹੈ।
ਆਟੋਮੋਟਿਵ EMC/EMI ਨਤੀਜੇ ਨਵੇਂ ਚਿਪ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ edge rates, ਘੜੀ, spread-spectrum ਵਿਕਲਪ, ਅਤੇ ਡ੍ਰਾਇਵਰ ਤਾਕਤ ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ। Ethernet, CAN, ਜਾਂ ਤੇਜ਼ SPI ਲਿੰਕਜ਼ 'ਤੇ ਸਿਗਨਲ ਇੰਟੀਗ੍ਰਿਟੀ ਲਈ ਟਰਮੀਨੇਸ਼ਨ, ਰੂਟਿੰਗ ਸੀਮਾਵਾਂ, ਜਾਂ ਕਾਮਨ-ਮੋਡ ਚੋਕਸ ਨੂੰ ਮੁੜ-ਟਿਊਨ ਕਰਨ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ।
ਸੱਚਾ ਡ੍ਰਾਪ-ਇਨ ਰੀਪਲੇਸਮੈਂਟ ਮਤਲਬ ਹੈ ਪੈਕੇਜ, ਪਿਨਆਉਟ, ਪਾਵਰ, ਘੜੀਆਂ, ਪੈਰੀਫੇਰਲ, ਅਤੇ ਬਿਜਲੀਕ ਵਿਹਾਰ ਇਸ ਹੱদ ਤੱਕ ਮਿਲਦੇ ਹਨ ਕਿ ਸੇਫਟੀ, EMC, ਅਤੇ ਮੈਨੂਫੈਕਚਰਿੰਗ ਟੈਸਟ ਫੁਟਰੇ ਪਾਸ ਹੋ ਜਾੲ਼। ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਅਕਸਰ ਪਾਉਂਦੀਆਂ ਹਨ ਕਿ “ਕੰਪੈਟਿਬਲ” ਚਿਪ ਸਿਰਫ਼ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਅਤੇ ਮੁੜ-ਵੈਧਤਾ ਤੋਂ ਬਾਅਦ ਹੀ ਸਹੀ ਹੋ ਜਾਂਦੀ ਹੈ—ਜੋ ਉਹਨਾਂ ਨੇ ਟਾਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ।
ਆਟੋਮੇਕਰ ਐਕਲੋੜ ਕੇਵਲ ਅੱਜ ਦੀ ਪ੍ਰਦਰਸ਼ਨ ਲਈ MCU ਨਹੀਂ ਚੁਣਦੇ—ਉਹ ਦੈਸੱਕ (ਜਾਂ ਹੋਰ) ਦੀਆਂ ਜਿੰਮੇਵਾਰੀਆਂ ਲਈ ਵੀ ਚੁਣਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਨਿਰਧਾਰਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਪੇਸ਼ਬੀਨੀਯੋਗ ਉਪਲਬਧਤਾ, ਸਥਿਰ ਵਿਸ਼ੈਸ਼ਤਾ, ਅਤੇ ਇਹ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ ਕਿ ਭਾਗ, ਪੈਕੇਜ, ਜਾਂ ਪ੍ਰਕਿਰਿਆ ਬਦਲਣ ਤੇ ਕੀ ਹੋਏਗਾ।
ਆਟੋਮੋਟਿਵ ਪ੍ਰੋਗਰਾਮ ਗਾਰੰਟੀ ਕੀਤੇ ਸਪਲਾਈ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਦੇ ਹਨ। NXP Semiconductors ਵਰਗੇ ਵੇਂਡਰ ਅਕਸਰ ਲਾਂਗੇਵਿਟੀ ਪ੍ਰੋਗਰਾਮ ਅਤੇ PCN (Product Change Notification) ਪ੍ਰਕਿਰਿਆਵਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ OEMs ਅਤੇ Tier 1s wafer ਸਮਰੱਥਾ, ਫਾਉਂਡਰੀ ਤਬਦੀਲੀਆਂ, ਅਤੇ ਕੰਪੋਨੈਂਟ ਅਲੋਕੇਸ਼ਨ ਦੀ ਹਕੀਕਤਾਂ ਦੇ ਆਸ-ਪਾਸ ਯੋਜਨਾ ਬਣਾ ਸਕਣ। ਇਹ ਸਿਰਫ਼ “ਅਸੀਂ ਇਸਨੂੰ ਸਾਲਾਂ ਤੱਕ ਵੇਚਾਂਗੇ” ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਇਹ ਵੀ ਹੁੰਦਾ ਹੈ ਕਿ “ਅਸੀਂ ਬਦਲਾਅ ਨੂੰ ਹੌਲੇ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਬੰਧ ਕਰਾਂਗੇ,” ਕਿਉਂਕਿ ਛੋਟੇ-ਛੋਟੇ ਸੰਸ਼ੋਧਨਾਂ ਵੀ ਮੁੜ-ਵੈਧਤਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਵਾ ਸਕਦੇ ਹਨ।
SOP ਤੋਂ ਬਾਅਦ, ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਨਵੇਂ ਫੀਚਰਾਂ ਤੋਂ ਸਸਟੀਨਿੰਗ ਇੰਜੀਨੀਅਰਿੰਗ ਵੱਲ ਸਖ਼ਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ BOM ਦੀ ਬਣਾਈਯੋਗਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ, ਗੁਣਵੱਤਾ ਅਤੇ ਭਰੋਸਣਯੋਗਤਾ ਦੀ ਨਿਗਰਾਨੀ, errata ਦਾ ਪਤਾ ਲਗਾ ਕੇ ਹੱਲ ਕਰਨਾ, ਅਤੇ ਨਿਯੰਤਰਿਤ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨਾ (ਉਦਾਹਰਣ ਲਈ, ਬਦਲੇ ਹੋਏ ਅਸੈਂਬਲੀ ਸਾਈਟਾਂ ਜਾਂ ਪਰਖ ਫਲੋ)। ਇਸਦੇ ਬਦਲੇ ਵਿੱਚ ਨਵਾਂ ਵਿਕਾਸ ਉਹ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਟੀਮਾਂ ਫਿਰੋਂ-ਫਿਰੋਂ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸਪਲਾਇਰਾਂ 'ਤੇ ਸੋਚ ਸਕਦੀਆਂ ਹਨ।
ਜਦੋਂ ਸਸਟੇਨਿੰਗ ਇੰਜੀਨੀਅਰਿੰਗ ਹਕੂਮਤ ਕਰਦੀ ਹੈ, ਤਰਜੀਹ ਕਨਟੀਨਿਊਟੀ ਬਣ ਜਾਂਦੀ ਹੈ—ਇੱਕ ਹੋਰ ਕਾਰਨ ਕਿ ਚਿਪ ਚੋਣਾਂ “ਸਟਿੱਕੀ” ਰਹਿੰਦੀਆਂ ਹਨ।
ਦੂਸਰਾ-ਸਰੋਤ ਰਿਸਕ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਧਾਰਨ ਨਹੀਂ ਹੁੰਦਾ ਕਿ “ਡ੍ਰਾਪ-ਇਨ” ਬਦਲੀ ਹੋ ਜਾਵੇ। ਪਿਨ-ਟੂ-ਪਿਨ ਵਿਕਲਪ ਸੇਫਟੀ ਦਸਤਾਵੇਜ਼, ਪੈਰੀਫੇਰਲ ਵਿਹਾਰ, ਟੂਲਚੇਨ, ਟਾਈਮਿੰਗ, ਜਾਂ ਮੈਮੋਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਵੀ ਫਰਕ ਲੈ ਕੇ ਆ ਸਕਦੇ ਹਨ। ਭਾਵੇਂ ਦੂਸਰਾ ਸਰੋਤ ਮੌਜੂਦ ਹੋਵੇ, ਉਸਨੂੰ ਯੋਗਤ ਕਰਨ ਲਈ ਅਕਸਰ ਵਾਧੂ AEC-Q100 ਸਬੂਤ, ਸਾਫਟਵੇਅਰ ਰਿਗ੍ਰੈਸ਼ਨ, ਅਤੇ ISO 26262 ਅਧੀਨ ਫੰਕਸ਼ਨਲ ਸੇਫਟੀ ਮੁੜ-ਕੰਮ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ—ਉਹ ਲਾਗਤਾਂ ਜਿਹਨਾਂ ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਬਚਣਾ ਪਸੰਦ ਕਰਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਸਪਲਾਈ ਦਬਾਅ ਜ਼ਬਰਦਸਤ ਨਾ ਹੋਵੇ।
ਵਾਹਨ ਪ੍ਰੋਗਰਾਮ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦਨ ਸਪਲਾਈ ਦੇ ਸਾਲਾਂ ਨਾਲ-ਨਾਲ ਸਪੇਅਰ ਪਾਰਟਸ ਅਤੇ ਸਰਵਿਸ ਲਈ ਇੱਕ ਵਧੀਆ ਟੇਲ ਵੀ ਮੰਗਦੇ ਹਨ। ਉਹ ਸਰਵਿਸ ਹੋਰਾਈਜ਼ਨ ਹਰ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ—ਲਾਸਟ-ਟਾਈਮ-ਬਾਈ ਯੋਜਨਾਬੰਦੀ ਤੋਂ ਲੈ ਕੇ ਸਟੋਰੇਜ ਅਤੇ ਟਰੇਸਬਿਲਟੀ ਨੀਤੀਆਂ ਤੱਕ। ਜਦੋਂ ਇੱਕ ਚਿਪ ਪਲੇਟਫਾਰਮ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਲੰਮੇ ਉਤਪਾਦ ਜੀਵਨ ਚੱਕਰਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਇਹ ਘੱਟ ਜੋਖਮ ਵਾਲਾ ਰਾਸਤਾ ਬਣ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਸਭ ਤੋਂ ਔਖਾ।
ਆਟੋਮੋਟਿਵ ਸਿਰਫ਼ ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਪਰ ਓਸੇ “ਸਟਿੱਕੀਨੈਸ” ਦੇ ਰੁਝਾਨ ਐਂਬੈੱਡਡ ਬਾਜ਼ਾਰਾਂ ਵਿੱਚ ਵੀ ਮਿਲਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜਿੱਥੇ ਡਾਉਨਟਾਈਮ ਮਹਿੰਗਾ ਹੈ, ਨਿਯਮ ਅਨਿਵਾਰ्य ਹਨ, ਅਤੇ ਉਤਪਾਦ ਦਹਾਕਿਆਂ ਤੱਕ ਸਰਵਿਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।
ਉਦਯੋਗਿਕ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ, ਇੱਕ ਕੰਟਰੋਲਰ ਜਾਂ ਮੋਟਰ ਡਰਾਈਵ ਸਾਲਾਂ ਤੱਕ 24/7 ਚੱਲ ਸਕਦਾ ਹੈ। ਇੱਕ ਅਚਾਨਕ ਕੰਪੋਨੈਂਟ ਬਦਲਾਅ ਟਾਈਮਿੰਗ, EMC ਵਿਹਾਰ, ਤਾਪਮਾਨ ਮਾਰਜਿਨ, ਅਤੇ ਫ਼ੀਲਡ ਭਰੋਸਣਯੋਗਤਾ ਦੀ ਮੁੜ-ਵੈਧਤਾ ਨੂੰ ਤਰੱਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਭਾਵੇਂ ਨਵਾਂ ਚਿਪ “ਬਿਹਤਰ” ਹੋਵੇ, ਇਸਨੂੰ ਸਾਬਤ ਕਰਨ ਦਾ ਕੰਮ ਲਾਭ ਨੂੰ ਵੱਧਤਰੇ ਬਦਲਾਅ ਦੇ ਖ਼ਿਲਾਫ਼ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਸ ਲਈ ਫੈਕਟਰੀਆਂ ਅਕਸਰ ਸਥਿਰ MCU ਅਤੇ SoC ਪਰਿਵਾਰਾਂ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਲੰਮੇ-ਅਵਧੀ NXP Semiconductors ਲਾਈਨਾਂ ਵੀ ਸ਼ਾਮਿਲ ਹਨ) ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ ਪਿਨਆਊਟ, ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਪਲਾਈ ਪ੍ਰੋਗਰਾਮ, ਅਤੇ ਧੀਰੇ-ਧੀਰੇ ਪ੍ਰਦਰਸ਼ਨ ਅੱਪਗ੍ਰੇਡ ਦੇ ਨਾਲ ਅਨੁਮਤੀਆਂ ਦਿੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਟੀਮਾਂ ਬੋਰਡ, ਸੇਫਟੀ ਕੇਸ ਅਤੇ ਟੈਸਟ ਫਿਕਸਚਰਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਦੇ ਯੋਗ ਬਣਦੀਆਂ ਹਨ ਨਾ ਕਿ ਨਵਾਈ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਗੀਆਂ।
ਮੈਡੀਕਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਕੜੇ ਨਿਯਮ-ਅਨੁਸਾਰ ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਮੰਗਾਂ ਦਾ ਸਾਹਮਣਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਐਂਬੈੱਡਡ ਪ੍ਰੋਸੈਸਰ ਬਦਲਣਾ ਵੈਰੀਫਿਕੇਸ਼ਨ ਯੋਜਨਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ, ਸਾਈਬਰਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਅਪਡੇਟ ਕਰਨ, ਅਤੇ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਦੁਹਰਾਉਣ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ—ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਸ਼ਿਪਮੈਂਟ ਨੂੰ ਦੇਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਆਲਿਟੀ ਟੀਮਾਂ ਨੂੰ ਬੰਧ੍ਹਦਾ ਹੈ।
ਇੰਫਰਾਸਟਰੱਕਚਰ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ 'ਤੇ ਹੋਰ ਦਬਾਅ ਅਪਟੀਮਮ ਹੈ: ਉਪਸਟੀਸ਼ਨ, ਸਮਾਰਟ ਮੀਟਰ, ਅਤੇ ਕਮਿਊਨੀਕੇਸ਼ਨ ਗੇਟਵੇਜ਼ ਵਿਸ਼ਾਲ ਪੱਧਰ 'ਤੇ ਲਗਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਖ਼ਤ ਹਾਲਾਤਾਂ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਕੰਮ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕੰਪੋਨੈਂਟ ਸਵੈਪ ਸਿਰਫ਼ BOM ਬਦਲਣਾ ਨਹੀਂ; ਇਹ ਨਵੀਂ ਵਾਤਾਵਰਣ ਟੈਸਟਿੰਗ, ਫਰਮਵੇਅਰ ਮੁੜ-ਯੋਗਤਾ, ਅਤੇ ਫੀਲਡ ਰੋਲਆਊਟ ਯੋਜਨਾ ਨੂੰ ਲੋੜੀਂਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਸਾਰਿਆਂ ਬਾਜ਼ਾਰਾਂ ਵਿੱਚ, ਪਲੇਟਫਾਰਮ ਦੀ ਸਥਿਰਤਾ ਇੱਕ ਫੀਚਰ ਬਣ ਜਾਂਦੀ ਹੈ:
ਨਤੀਜਾ ਆਟੋਮੋਟਿਵ ਡਿਜ਼ਾਈਨ-ਇਨ ਗਤੀਵਿਧੀਆਂ ਨਾਲ ਮਿਲਦਾ ਹੈ: ਜਦੋਂ ਇੱਕ ਐਂਬੈੱਡਡ ਚਿਪ ਪਰਿਵਾਰ ਕਿਸੇ ਉਤਪਾਦ ਲਾਈਨ ਵਿੱਚ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ ਉਸ ਤੇ ਕੁਝ ਸਾਲਾਂ ਤੱਕ ਹੀ ਬਣਾਉਂਦੀਆਂ ਹਨ—ਕਿਉਂਕਿ ਅਸਲ ਲਾਗਤ ਸਿਲਿਕਾਨ ਨਹੀਂ, ਪਰ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਜਮ੍ਹੇ ਸਬੂਤ ਅਤੇ ਭਰੋਸਾ ਹੁੰਦਾ ਹੈ।
ਆਟੋਮੋਟਿਵ ਟੀਮਾਂ ਇੱਕ ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਨੂੰ ਹਲਕੇ-ਫੁਲਕੇ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀਆਂ, ਪਰ ਇਹ ਕੁਝ ਹਾਲਤਾਂ 'ਚ ਹੁੰਦਾ ਹੈ—ਅਕਸਰ ਜਦੋਂ ਬਾਹਰੀ ਦਬਾਅ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਵੈਪ ਨੂੰ ਇੱਕ ਛੋਟੇ-ਪ੍ਰੋਗਰਾਮ ਵਾਂਗ ਦੇਖੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਖਰੀਦ ਫੈਸਲਾ।
ਆਮ ਤਰੱਕੀਆਂ ਸ਼ਾਮਿਲ ਹਨ:
ਸਭ ਤੋਂ ਵਧੀਆ ਰਾਹ ਪਹਿਲੇ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਡਿਜ਼ਾਈਨ-ਇਨ ਚੱਕਰ ਦੌਰਾਨ ਸ਼ੁਰੂਆਤੀ ਵਿਕਲਪ (ਪਿਨ-ਕੰਪੈਟਿਬਲ ਜਾਂ ਸਾਫਟਵੇਅਰ-ਕੰਪੈਟਿਬਲ) ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਉਹ ਕਦੇ ਉਤਪਾਦਨ ਵਿੱਚ ਨਾ ਜਾਣ। ਉਹ ਮੋਡੀਊਲਰ ਹਾਰਡਵੇਅਰ ਲਈ ਦਾਬ ਦਿੰਦੀਆਂ ਹਨ (ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਪਾਵਰ, ਕਮਿਊਨਜ਼, ਅਤੇ ਕੰਪਿਊਟ ਵੱਖ-ਵੱਖ) ਤਾਂ ਜੋ ਇੱਕ ਚਿਪ ਬਦਲਣ ਨਾਲ ਪੂਰੀ PCB ਰੀ-ਡਿਜ਼ਾਈਨ ਨਾ ਹੋਏ।
ਸਾਫਟਵੇਅਰ ਪਾਸੇ, ਏਬਸਟ੍ਰੈਕਸ਼ਨ ਲੇਅਰ ਮਦਦ ਕਰਦੇ ਹਨ: ਚਿਪ-ਵਿਸ਼ੇਸ਼ ਡ੍ਰਾਇਵਰ (CAN, LIN, Ethernet, ADC, timers) ਨੂੰ ਸਥਿਰ ਇੰਟਰਫੇਸਾਂ ਦੇ ਪਿੱਛੇ ਅਲੱਗ ਰੱਖੋ ਤਾਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਜ਼ਿਆਦਾਤਰ ਅਣਛੁਆ ਰਿਹੇ। ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ MCU ਪਰਿਵਾਰਾਂ ਵਿੱਚ (ਇੱਕ ਵੇਂਡਰ ਪੋਟਰਫੋਲਿਓ ਅੰਦਰ ਵੀ) ਸਥਾਨਾਂਤਰ ਕਰ ਰਹੇ ਹੋ—ਕਿਉਂਕਿ ਟੂਲਿੰਗ ਅਤੇ ਨੀਵੀਂ ਸਤਰ ਦਾ ਵਿਵਹਾਰ ਫਰਕ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਾਸਤਵਿਕ ਨੋਟ: ਇੱਕ ਸਵੈਪ ਵਿੱਚ bahut ਸੋਧ-ਮੁਲਕ ਕੰਮ ਕੋਆਰਡੀਨেশਨ ਹੁੰਦੀ ਹੈ—ਜੇ ਕਿਹਾ ਕਿ ਕੀ ਬਦਲਿਆ, ਕਿਸਨੂੰ ਮੁੜ-ਟੈਸਟ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਿੜਾ ਸਬੂਤ ਪ੍ਰਭਾਵਿਤ ਹੋ ਰਿਹਾ ਹੈ। ਕੁਝ ਟੀਮਾਂ ਇਸ ਘਿਸਟ ਨੂੰ ਘਟਾਉਣ ਲਈ ਹਲਕੇ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਚੇਂਜ-ਕੰਟਰੋਲ ਡੈਸ਼ਬੋਰਡ, ਟੈਸਟ-ਟ੍ਰੈਕਿੰਗ ਪੋਰਟਲ, ਆਡੀਟ ਚੈੱਕਲਿਸਟ)। ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਇੱਥੇ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਤੁਹਾਨੂੰ ਇਨ੍ਹਾਂ ਨਾਲ ਗੱਲ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਬਸ ਐਪ ਬਣਾਉਣ, ਫਿਰ ਸਰੋਤ ਕੋਡ ਨਿਕਾਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲ ਸਕਦੀ ਹੈ—ਜੋ ਵਰਤੋਂ ਯੋਗ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਇੱਕ ਕਸਟਮ ਵਰਕਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਲੋੜ ਹੋਵੇ ਬਿਨਾਂ ਮੁੱਖ ECU ਇੰਜੀਨੀਅਰਿੰਗ ਸ਼ੈਡਿਊਲ ਨੂੰ ਡਰਾਈਵ ਕਰਨ ਦੇ।
ਇੱਕ ਸਵੈਪ ਸਿਰਫ਼ “ਬੂਟ ਹੁੰਦਾ ਹੈ?” ਦਾ ਸਵਾਲ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਵੱਡੀ ਹਿੱਸੇ ਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਮੁੜ-ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ: ਟਾਈਮਿੰਗ, ਡਾਇਗਨੋਸਟਿਕਸ, ਫੌਲਟ ਹੈਂਡਲਿੰਗ, ਅਤੇ ਸੇਫਟੀ ਮਕੈਨਿਜ਼ਮ (ਉਦਾਹਰਣ ਲਈ ISO 26262 ਦੇ ਕਾਰਜ). ਹਰ ਇੱਕ ਬਦਲਾਅ ਦਸਤਾਵੇਜ਼ੀ ਅਪਡੇਟਾਂ, ਟਰੇਸਬਿਲਟੀ ਚੈੱਕਾਂ, ਅਤੇ ਮੁੜ-ਅਨੁਮੋਦਨ ਚਕਰਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਤਾਪਮਾਨ, ਵੋਲਟੇਜ, ਅਤੇ ਏਜ ਕੇਸز 'ਤੇ ਹਫ਼ਤਿਆਂ ਦੀ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ।
ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਬਦਲਾਅ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਦਾ “ਹਾਂ” ਉਤਰ ਦੇ ਸਕੋ:
ਆਟੋਮੋਟਿਵ ਅਤੇ ਐਂਬੈੱਡਡ ਚਿਪਾਂ "ਸਟਿੱਕ" ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫੈਸਲਾ ਸਿਰਫ਼ ਸਿਲਿਕਾਨ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਉਸ ਪਲੇਟਫਾਰਮ ਨੂੰ ਕਮਿੱਟ ਕਰਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ ਜੋ ਸਾਲਾਂ ਤੱਕ ਸਥਿਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪਹਿਲਾਂ, ਡਿਜ਼ਾਈਨ-ਇਨ ਚੱਕਰ ਲੰਮਾ ਅਤੇ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ECU ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ, ਟੀਮਾਂ ਉਸ ਠੀਕ ਭਾਗ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਕੈਮੈਟਿਕ, PCB, ਪਾਵਰ ਡਿਜ਼ਾਈਨ, EMC ਕੰਮ, ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਬਾਅਦ ਵਿੱਚ ਉਸਨੂੰ ਬਦਲਣਾ ਇੱਕ ਚੇਨ-ਰੀਐਕਸ਼ਨ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।
ਦੂਜਾ, ਸੇਫਟੀ ਅਤੇ ਕੰਪਲਾਇੰਸ ਸਵਿੱਚਿੰਗ ਲਾਗਤਾਂ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ। ਫੰਕਸ਼ਨਲ ਸੇਫਟੀ ਉਮੀਦਾਂ (ਅਕਸਰ ISO 26262 ਨਾਲ ਸੰਬੰਧਿਤ) ਦਸਤਾਵੇਜ਼, ਸੇਫਟੀ ਵਿਸ਼ਲੇਸ਼ਣ, ਟੂਲ ਯੋਗਤਾ, ਅਤੇ ਨਿਯੰਤਰਿਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ। ਭਰੋਸਣਯੋਗਤਾ ਉਮੀਦਾਂ (ਆਮ ਤੌਰ 'ਤੇ AEC-Q100 ਅਤੇ ਗਾਹਕ-ਵਿਸ਼ੇਸ਼ ਟੈਸਟ ਯੋਜਨਾਵਾਂ ਨਾਲ ਜੋੜੀਆਂ) ਹੋਰ ਸਮਾਂ ਅਤੇ ਸਬੂਤ ਜੋੜਦੀਆਂ ਹਨ। ਇੱਕ ਚਿਪ ਤਦ ਹੀ “ਮਨਜ਼ੂਰ” ਹੁੰਦਾ ਹੈ ਜਦ ਪੂਰਾ ਸਿਸਟਮ ਮਨਜ਼ੂਰ ਹੋ ਜਾਵੇ।
ਤੀਜਾ, ਸਾਫਟਵੇਅਰ ਚੋਣ ਨੂੰ ਪੱਕਾ ਕਰਦਾ ਹੈ। ਡ੍ਰਾਇਵਰ, ਮਿਡਲਵੇਅਰ, ਬੂਟਲੋਡਰ, ਸੁਰੱਖਿਆ ਮਾਡਿਊਲ, AUTOSAR ਸਟੈਕ ਅਤੇ ਅੰਦਰੂਨੀ ਟੈਸਟ ਸੂਟ ਇੱਕ ਖਾਸ ਪਰਿਵਾਰ ਲਈ ਲਿਖੇ ਅਤੇ ਟਿਊਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਪੋਰਟਿੰਗ ਸੰਭਵ ਹੈ, ਪਰ ਇਹ ਕਦੇ ਵੀ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦੀ—ਅਤੇ ਸੇਫਟੀ-ਸੰਬੰਧੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰਿਗ੍ਰੈਸ਼ਨ ਸਹਿਣ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।
NXP Semiconductors ਵਰਗੇ ਸਪਲਾਇਰਾਂ ਲਈ, ਇਹ ਸਟਿੱਕੀਨੈਸ ਉਤਪਾਦਨ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਾਂ ਦੇ ਇੱਕ ਵਾਰ ਲੌਂਚ ਹੋਣ ਤੋਂ ਬਾਅਦ ਥੋੜ੍ਹੀ ਹੋਰ ਸਥਿਰ, ਵੱਧ ਅਨੁਮਾਨਯੋਗ ਮੰਗ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਸਕਦੀ ਹੈ। ਵਾਹਨ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਐਂਬੈੱਡਡ ਉਤਪਾਦ ਅਕਸਰ ਸਾਲਾਂ ਤੱਕ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਸਪਲਾਈ ਦੀ ਲਗਾਤਾਰ ਯੋਜਨਾ ਰਿਸ਼ਤੇ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ—ਕੋਈ ਬਾਅਦ ਵਿੱਚ ਦੀ ਗੱਲ ਨਹੀਂ।
ਲੰਬੇ ਜੀਵਨ ਚੱਕਰ ਨਵੇਂ ਅਪਗਰੇਡ ਨੂੰ ਵੀ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ। ਭਾਵੇਂ ਇੱਕ ਨਵਾਂ ਨੋਡ, ਫੀਚਰ, ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਆਕਰਸ਼ਕ ਲੱਗੇ, "ਬਦਲਣ ਦੀ ਲਾਗਤ" ਫਾਇਦੇ ਤੋਂ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਵੱਡਾ ਪਲੇਟਫਾਰਮ ਰੀਫ੍ਰੈਸ਼ ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਨਾਲ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹੋਰ ਸੰਬੰਧਤ ਪੋਸਟਾਂ ਵੇਖੋ, ਜਾਂ ਵੇਖੋ ਕਿ ਵਪਾਰਕ ਸ਼ਰਤਾਂ ਕਿਵੇਂ ਪਲੇਟਫਾਰਮ ਚੋਣਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਸਟਿੱਕੀ” ਦਾ ਮਤਲਬ ਇੱਕ ਐਸੀ ਸੈਮੀਕੰਡਕਟਰ ਹੈ ਜੋ ECU ਜਾਂ ਐਂਬੈੱਡਡ ਉਤਪਾਦ ਲਈ ਚੁਣੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਬਦਲਣਾ ਔਖਾ ਅਤੇ ਮਹਿੰਗਾ ਹੋ ਜਾਵੇ। ਜਦੋਂ ਇਹ designed in ਹੋ ਜਾਂਦਾ ਹੈ (ਹਾਰਡਵੇਅਰ ਕਨੈਕਸ਼ਨ, ਫਰਮਵੇਅਰ, ਸੇਫਟੀ ਸਬੂਤ, ਟੈਸਟ ਅਤੇ ਉਤਪਾਦਨ ਪ੍ਰਵਾਹ), ਤਾਂ ਇਸਨੂੰ ਬਦਲਣ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਵਿਆਪਕ ਦੁਬਾਰਾ ਕੰਮ ਅਤੇ ਸਮਾਂ-ਜੁੜੇ ਖਤਰੇ ਉੱਠਦੇ ਹਨ।
ਕਿਉਂਕਿ ਚਿਪ ਚੋਣ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਸਾਲਾਂ ਤੱਕ ਸਥਿਰ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ design win ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਕਿਸੇ ਖਾਸ ਗਾਹਕ ਪ੍ਰੋਗਰਾਮ ਲਈ ਇੱਕ ਨਿਰਧਾਰਤ ਚਿਪ ਚੁਣ ਲਈ ਜਾਂਦੀ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਕਿਸੇ ਵਾਹਨ ਪਲੇਟਫਾਰਮ 'ਤੇ ECU)। ਵਿਹਾਰਿਕ ਤੌਰ ਤੇ, ਇਸ ਦਾ ਅਰਥ ਹੁੰਦਾ ਹੈ ਕਿ ਟੀਮਾਂ:
ਸਭ ਤੋਂ ਵਧੀਆ ਖਿੜਕੀਆਂ ਸ਼ੁਰੂਆਤੀ ਹੁੰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕੰਮ ਅਜੇ ਤੱਕ ਲੌਕ-ਇਨ ਨਹੀਂ ਹੋਇਆ:
ISO 26262 ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਪ੍ਰਕਿਰਿਆ ਲਗਾਂਦਾ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਜੋਖਮ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਅਧਾਰ ਦੇ ਨਾਲ ਸਾਬਤ ਕਰਨ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਮੁੜ-ਰਿਵੀਅਰ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ:
ਇੱਕ safety concept ਇਹ ਯੋਜਨਾ ਹੈ ਕਿ ਸਿਸਟਮ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਰਹੇਗਾ (ਡਾਇਗਨੋਸਟਿਕਸ, ਰਿਡੰਡੰਸੀ, ਫੌਲਟ ਰਿਐਕਸ਼ਨ)। ਇੱਕ safety case ਉਹ ਗਠਿਤ ਦਲੀਲ ਹੈ—ਜੋ ਦਸਤਾਵੇਜ਼, ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਟੈਸਟ ਰਿਪੋਰਟਾਂ ਨਾਲ ਸਮਰਥਿਤ ਹੁੰਦੀ ਹੈ—ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਯੋਜਨਾ ਠੀਕ ਤਰ੍ਹਾਂ ਲਾਗੂ ਅਤੇ ਵੈਰੀਫਾਈ ਕੀਤੀ ਗਈ।
ਚਿਪ ਬਦਲਣ ਨਾਲ ਅਕਸਰ ਦੋਵੇਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਬੂਤ ਨਿਰਧਾਰਿਤ ਚਿਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
AEC-Q100 ਇੱਕ ਆਮ ਵਰਤੀ ਜਾਂਦੀ ਆਟੋਮੋਟਿਵ ਯੋਗਤਾ ਫਰੇਮਵਰਕ ਹੈ ਜੋ ਇੱਕ ਇੰਟੇਗ੍ਰੇਟਿਡ ਸਰਕਿਟ ਲਈ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਇਸ ਲਈ ਹੈ ਕਿ ਇਹ ਉਤਪਾਦਨ-ਉਪਯੋਗ ਲਈ ਇੱਕ ਗੇਟ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ: OEMs ਅਤੇ Tier 1s ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਯੰਤਰਕਾਂਡ ਤਾਪਮਾਨ ਚੱਕਰ, ਬਿਦਿਉਤਿਕ ਤਣਾਓ ਅਤੇ ਹੋਰ ਆਟੋਮੋਟਿਵ ਸਟ੍ਰੈੱਸਾਂ ਹੇਠ ਡਿਵਾਇਸ ਨੇ ਪੇਸ਼ਬੀਨੀ ਅਨੁਕੂਲ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਪੈਦਾ।
ਲੈਬ ਜਾਂ ਪ੍ਰੋਟੋਟਾਇਪ ਵਿੱਚ ਚੰਗੀ ਹੋਣ ਵਾਲੀ ਇੱਕ ਗੈਰ-ਯੋਗਤ ਡਿਵਾਇਸ ਨੂੰ ਉਤਪਾਦਨ ਲਈ ਮਨਜ਼ੂਰ ਕਰਵਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।
ਕਿਉਂਕਿ ਚਿਪ ਚੋਣ ਇੱਕ ਸਾਫਟਵੇਅਰ ਵਾਤਾਵਰਣ ਨੂੰ ਵੀ ਚੁਣਦੀ ਹੈ:
ਹਾਂ, “ਕੰਪੈਟਿਬਲ” ਹਾਰਡਵੇਅਰ ਵੀ ਆਮ ਤੌਰ 'ਤੇ ਪੋਰਟਿੰਗ ਅਤੇ ਵਿਆਪਕ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ।
ਨਵਾਂ ਭਾਗ ਅਕਸਰ ਬਿਲਕੁਲ 'BOM-ਸਿਰਫ' ਤਬਦੀਲੀ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਨਵੇਂ ਹਿੱਸੇ ਨਾਲ:
ਇਸ ਲਈ ਸੱਚੇ “ਡ੍ਰੌਪ-ਇਨ ਰੀਪਲੇਸਮੈਂਟ” ਘੱਟ ਹੀ ਮਿਲਦੇ ਹਨ।
ਟੱਪ ਤੇ ਬਾਹਰੀ ਦਬਾਅ ਅਕਸਰ ਬਦਲਾਅ ਨੂੰ ਆਵਸ਼ਯਕ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ:
ਟਿਮਾਂ ਜੋਖਮ ਘਟਾਉਣ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਵਿਕਲਪ ਨਿਰਧਾਰਿਤ ਕਰਦੀਆਂ ਹਨ, ਮੋਡੀਊਲਰ ਹਾਰਡਵੇਅਰ ਵਰਤਦੀਆਂ ਹਨ ਅਤੇ ਚਿਪ-ਵਿਸ਼ੇਸ਼ ਕੋਡ ਨੂੰ ਏਬਸਟ੍ਰੈਕਸ਼ਨ ਲੇਅਰ ਪਿੱਛੇ ਰੱਖਦੀਆਂ ਹਨ—ਫਿਰ ਵੀ, ਰੀ-ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਅੱਪਡੇਟ ਲਈ ਸਮਾਂ ਬਜਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ।