BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-11

saltuzzo | 27 June, 2018 17:17

Part 11: IoT Core Platform Development - Product Development Management
The IoT Embedded Core Platform -Design Documentation Processes

"There is no greater impediment to the advancement of knowledge than the ambiguity of words." - Thomas Reid (1710-1796)

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018) 
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)

Quick review to set the atmosphere for Part 10
From the previous Internet of Things Part-1 through Part- 10:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology, Overview → Basic → Detailed (OBD).  We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The atmosphere has been set for the Internet operation overview in parts 1 through 10.
  • The Ethernet physical protocol is the most used for communications over the Internet.
  • All communications throughout the Internet is performed as UserRouterInternet RoutersRouterUser
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • Basic types of CPU architecture on the market today
  • The internals of the embedded processor IC's peripherals assignments.

What we want to cover in Part 11:

OK, we have covered interesting technical stuff for the overview of what our IoT core Platform should be.  At this time we will cover the basics of documentation, records we should create to insure our design policies and guide lines are covered properly to insure a successful project development.

Yes, I know the temptation, the excitement and anticipation of just jumping right in and designing the hardware and software on the fly and documenting it later, did that many years ago several times and found that way was not very productive during the testing and troubleshooting stages of the development, ended up almost redesigning the device.

Since this is an educational project, lets set some healthy design practices to follow that we may use for many innovative designs to come.  We will discuss the basic requirements of an Interactive Product Development (IPD) System that uses relational databases for our development guide and make this system available at the end of the series.

Lets Get Started:
A Brief summary - Documenting Design Processes:
OK, This part of the series is about product development documentation discipline, I know engineers and experimenters just want to dive in and start connecting parts together on the bench and see what comes out of it.  That is OK, I still feel like that after all these years and at times just do that for a one time only design.  Go for it, you can always refer back here and learn the documentation discipline when you are ready for it.  

During my career one of my mentors stated that if you want to be a product development engineer you have to be responsible for problems that arise in manufacturing, hence, design the product for manufacturing because you will be directly involved in the testing and troubleshooting AND - problems do arise when going from Proof of Design (PoD) development to (PoM) Proof of Manufacturing.  Also just because the PoM worked, there will always be some issues when ramping up to quantity in manufacturing.   When a computer and software are part of the product it is a challenge to anticipate the full variations for a FMA (Failure Mode Analysis) matrix.

The advantage of writing a blog on product development is that we have the opportunity of writing about experiences in order to help the young engineer enter into the world of product design.  To maintain a positive point of view always even when addressing difficult problems that appear negative.

OK, lets address an on going issues of how a project schedule and budget gets out of hand, not something new, it has been an issue of the 38 years I have worked in the industry and it is independent of the field be it building facilities, homes, or computers or whatever.  The concept of going into business to sell product is to make a profit.  If you go over budget including time, the results are less profit and in some cases end of product and possibly company, so in order for this series to be both effective and efficient we should present an approach that addresses both. Oh, did I mention documentation processes, TBD (To Be Determined) and of course SWAG's (Silly Wild A$$ Guess) ?   "SWAGs and TBD will get you in difficulty every time, it is the way many larger contracts are compiled in order to compete and win the contract, only to pay the price later.  The more accurate the documentation is up front the better chances of a successful product development.

Traceability Documents
Experiments and development to maintain traceability in a document form has been an on-going challenge for over 100 years of the industrial revolution.  From Taylorism to the McNamara's WizKids and the implementation of Game Theory that is in all aspects of our lives.  What is interesting is you would think that after all these years the product development processes would have thinned out and stabilized.  As we stated in the previous part, scientific management systems work great after the product is fine tuned in manufacturing, it is still not very effective or efficient during the development process. Wow, sounds too negative, lets look at it a more positive way that is applied to startups and the geniuses that have a dream as with every startup.

Rational organization documents during the product development stages are considered by many designers as an "out-of -the-box-mind set" and should not be confined to a fixed scientific process mainly due to the fact that the innovative mind incorporates way too many variables as well as rapid change of direction to attempt creating a scientific formula to represent it at least during the innovation processes, after the initial design testing is another issue.  There are many documents that may be applied during product development and is usually refined at different stages of development, however it is not a totally spastic process, there are processes for parts of the innovation process, they are just better performed if allowed to be rearranged at times during the development.  They all should be completed by the end of the development cycle prior to being moved into a manufacturing environment, again which is a completely separate process for compliancy and unique validation.

There are many relational databases available but only a few real product development type relational databases that allow the storage of product development facts and data to allow Requirements Traceability and a Rational Cross Referencing Matrix, too many words for an acronym, however the short form is (RTM) Requirements Traceability Matrix, sound familiar?

Pros & Cons of Relational Databases and Spreadsheets:
Databases and more databases and spreadsheets to store and document information into a "data warehouse" of data.  There are many database software packages on the market today and many of them are able to be integrated into MS Windows® Visual Studio and Linux type operating systems to organize information.  The issue is an application that addresses an Interactive Product Development (IPD) environment.  Many database servers like MySql, PostgreSQL, MariaDB, MongoDB, SQLserver, NoSQL and the list goes on for the creation of the database interactively, however data input and retrieval are based on the actual application to retrieve the data in the proper form that makes an application useful.  Storing warehouses of data is relatively easy, retrieving and organizing the data to have proper meaning toward an application is another issue altogether, that is where a good Interactive Product Development system becomes priceless when traceability for components, modules, compliance and requirements need to be reviewed and validated to name a few of the advantages.

Relational Databases:
Relational Databases are a group of digital database tables that are based on a configured indexing model which allows all databases to be aligned to the related indexes for data retrieval and insertion based on the configured model. The relationships are related to a top level index such as the project ID and secondary indexes that allow sub-sections of the project to be retrieved synchronously to generate reports.  There are more advantages to using relational database tables for Interactive Product Development processes than there are disadvantages as many designers have debated.  BASIL Networks has developed a series of small data gathering formats and file that allowed us to interface with various clients document formats and as many SMB manufacturers do not have a full integrated system as some of the larger manufactures that have the financial resources to either develop or purchase.

Spreadsheets Pros and Cons:
Spreadsheets have many great applications for business, however when they are used for technical computations or as a pseudo database we get into difficulty.  Spreadsheets are and X/Y, Row/Column cell format and using them to do complex math and system design causes cell identification issues for understanding a computational process.  The way that the cells perform complex math like averaging multiple cells may be different when performing max/min error analysis on several connected modules.  A true max/min ripple analysis requires an iterative process for each connective modules max/min output to be used as the next modules input variable until all the max/min combinations of the modules are tested,  for 3 modules connected in series that would be 26 =  64 iterations for the 23 for max and 23 for the min data sets.

Many designers use a spreadsheet for the Requirements Traceability Matrix with test cases in a Row/Column format that may also get complex and difficult to read if there are many test cases to handle. Database tables on the other hand are easier to generate a report of any complex relationship and test cases as well as performance results for clarity.

Database Structures, Relationships, Reliability Traceability Documents:
So, for our core IoT Platform we will use the rational organization approach and integrate some relational database methodology that will incorporate MDM (Modular Design Methodology) that may be useful for many years to come. Since this is a core platform that may be applied to many of these critical industrial areas we will document the development and all components used for reliability and traceability to insure the maximum integrity of the core platform.  

Large projects are generally broken own into smaller sub-assembly modules that are categorized for "reuse" in other projects.  A relational database referencing these modules is a required tool for the systems developer, however reuse has issues as we will cover in the MDM section following.

There are many document types presented during a product development process since many different functions of a corporation are involved and require different document formats for each of these functions, of course all requiring access to the documentation system.  This is where the IPD systems becomes the key asset in the success of completing a project.   The IPD system should be considered a living system for tracking the development of a product from financial, marketing, engineering, testing, validation, certification,manufacturing and sales.  That is a lot of different information formats and types to handle.  Attempting to handle all this data independently without relational database structures flexible formats would make managing a complex project vulnerable to missing data for accurate status, hence the relational database system retrieves up to date status information for many departments working on the project.

These database tables will allow complete traceability during the development process and a index database table that keeps track of how each of these database tables are to be indexed for data retrieval.  The largest of these tables is the component databases, it is obvious that we do not want to be a parts distributor, however we would like a complete set of information on each part that a project uses including multiple sources and timelines for the part.  Many printed circuit board design packages do allow for integrated component selection, however they are limited to the electronic design of a board.

The Interactive Product Development relational databases have several common corporate wide databases that are used to manage the development, the main set of databases that are independently maintained usually by supply chain management are the components databases.  Components or parts databases are a unique set of databases that categorize all the raw parts used as a resource for the product development.  There are many categories for components and are broken down into several databases with the links to add other component categories as needed for growth.  The remaining databases are relational to the projects of which data may be retrieved for each of the several functions for reports and real time information about product development processes.

Many small and especially startup companies are slack in the documents and focus on getting the product to market first only to find later the cost of poor development documentation is very costly.  Implementing an Interactive Product Development system initially saves time and money as the product matures and the company grows.  Reports may be generated easily during the development process to manage the development process effectively, yes it does require discipline to enter the data as required during the development, including design notes that the designer encountered especially during test cases.  Entering data is where many designers negligent for many reasons and we all have our reasons, regardless, developing good engineering practices in the beginning pays off at the end.

The typical  Interactive Product Development system set of relational databases are outlined in Figure 11.0 below.  As we see the relational database with multiple index relationship functionality is a definite requirement to interconnect all the different information for project development tracking and analysis.  We will cover more on the IPD system prior to making it as a download for our readers at the end of this series.

As the author of this series I have thought of combining all the separate modules to create an IPD system for the Entrepreneur and have decided to give this an attempt using the document creations for this series.  The requirements are simple it has to interface with current day desktop and web applications easily, that is MS Windows, Linux, and Web Servers.  The use of  MySQL® table format is probably the simplest choice for all the IPD database applications since it is widely used, compatible with many operating systems and open source.  If you want to be part of this, click here to send me a note.

Since this is an educational series, BASIL Networks will be developing a full IPD system for those entrepreneurs that want to develop and manufacturer their own product lines from the processes we create during this series and will be available for downloading along with the Interactive BUS Protocol Development (IBPD) system at the end of the series.  

IPD_Databases
Figure 11.0 Interactive Product Development (IPD) System Relational Databases

[Section_Menu]     [Top_Menu]

MDM - Modular Design Methodology, The "Reuse" Module Dilemma:
Modular Design Methodology has been around for many decades in order to have manageability over large system developments such as the Internet, Automobile manufacturing and more that incorporate many sub-assemblies all connected together to form a product.  Well all this sounds great and is one of the main motivating leverages that drives the industry to the "REUSE" dilemma that modules can be reused for other projects, "however", not all modules are fit for reuse without extensive rework which puts the module outside of the plug and play requirements of the reuse category.

The reuse issue is a touchy subject matter for large corporations since the communications pipeline seems to get distorted as it travels throughout the engineering and management levels.  For larger corporations, hence automotive, aircraft, military weapon systems, power grid systems, cell tower base systems that all require full traceability down to the smallest component level, reuse would be great if it really existed to its full capability, however reality proves it does not, which sounds a bit oxymornic with today's data warehouses of information one would think that it would be easier to maintain more accurate records.

The Reality of Reuse:
In larger corporations the percentage of reuse modules "AS-IS" without rework is very small, over my 38 years in the industry the "AS-IS" module reuse appears to fall in the less than 5% region.  For modules that require 20% or more which is at the redesign point depending on the specific rework or specification change, average to around 30% over multiple product lines and require other system integration changes to incorporate them.  Beyond the 25% change region it should NOT be considered a reuse item and would or should be assigned a unique part number requiring full PoD, PoM, Validation and Certification.

Larger corporations still strive to develop modules for reuse within their organization and expect their in house technical expertise to perform these tasks over and above their normal assigned duties.  Do not get upset folks, this has been an active process for over 50 years that I am aware of, a little bit of positive stress bring out the achievers in all of us and is healthy for growth.  Some companies take the outsource approach expecting that "FFF" (Form-Fit-Function) identified the module as reuse even if from different manufacturers also has it pitfalls, this is the "Solutions Business Approach".  Many of these reuse endeavors end up costing more time, money and resources than it would be to manufacture a new item.  When we look at the evolution of the computer from the 1950's to present day we see many reuse examples of standardization that actually worked for the growth of the industry, hence: the Hard Disk Controller originally would require the reformatting of the drive if the controller had to be replaced. Today with SATA, controllers and drives are interchangeable. The standard graphics controller followed the standard 640x480 and 800x600 format regardless of any higher unique designs that required a custom driver. The USB and firewire, the keyboard and mouse controllers, these devices became the plug and play and followed the true reuse criteria of the industry.  The main reason is due to the fact that they became "Industrial Standards", however this is not true for many larger present day corporations as the Military Industrial Complex manufacturers that are constantly innovating and prototyping new technology and systems as well as the automotive industry that function much in the same innovative mode.  As with all technology and industries as the technology becomes widely used, standards are developed and the industry thins out to a few commodity players that have a large library of reuse modules such as the cell phones and CDMA modules, Bluetooth, WiFi, touch screen and camera modules.  

It appears that until a technology is understood and integrated into our everyday lives and becomes a standard the scientific manufacturing process such as Taylorism easily makes it a commodity for the masses.  In summary, technology changes fast, parts become discontinued, performance demands change continually and today's reuse module maybe absolute before its next application.  OK, enough for the industrial revolution history lesson, back to the IoT Core Platform development.

Document File Types and Data File Links:
There will exist many different document types during a product development cycle and keeping track of the different file types becomes a challenge.  Naming conventions for files and directories will help organize the development an information retrieval.  The directory naming convention used in the IPD system follows the same naming file and directory conventions as shown in the IBPD system shown in this site which has evolved over the years at BASIL Networks.  As for the document application software take your pick, however it is advised that the file formats should be compatible software to be able to communicate with other organizations outside your immediate development environment.

For Document creation many developers use MS Office, the startups and smaller entrepreneurs' find that open source LibreOffice is just as effective and efficient and allows easy read/write file exchange with other office documentation software.  At BASIL Networks, we use MS Office as well as LibreOffice in order to handle many different document types in the industry.  BASIL Networks IBPD system incorporates a general purpose Rich Text Format (*.rtf) editor we will also incorporate it into the IPD project since rich text formats are easily created via most word processors.  The RTF editor incorporated in the IBPD system is used for all abstracts of the different documentation file types that are linked via the relational database system, in some cases it may be used to outline the actual test setup.

Security, Intellectual Property
It is always a good idea to at least mention security and Intellectual Property since we are presenting product development processes.  It has been my experiences that ideas are a dime a dozen and many will forget they have been spoken, that is until someone applies that idea to fruition.  When there exists product it is at that point that the inclusive Intellectual Property (IP) becomes of interest to the hackers.  We all use computers to design, develop and create products with even being on-line during the process, which today is not a good practice to employ since many of the new processors have active management system internal to the processor chip.  It is recommended to uses an off-line (not accessible to the Internet (incoming or outgoing) when developing product that contain IP or trade secrets that you do not want to be hacked and sold to the highest bidder or worse.  Keeping a development server off line is not a difficult task, it is just a stand alone server that is connected to workstations, we have a few here and yes, we have desktops that are not connected to the Internet.  Encrypting all the development files is time consuming and at time a "Pain where the sun don't shine" however if you feel that the product you are developing is worth a large amount of money, then data protection has to be performed is some way.   We will cover real time encryption/decryption when we get into the software development stages for the series.  We are not concerned with encryption of this series since is a public education series.

With today's information hacking we do recommend a local off-line (air-gap, not wireless) server to save development files including the relational databases to insure some type of security from hackers.  Keep in mind that what ever you publish on-line should be consider open source for everyone and anyone to make copies regardless of any conditions you put with the publication.

[Section_Menu]      [Top_Menu]

SUMMARY:
Development documentation is and always will be a critical part of product development.  This is even more critical when it come to software coding.  There are thousands of lines of code free on the Internet, however when you try to read how it works there are little or no comments.   During the computer revolutions early days at Digital Equipment Corp (DEC) the programmers were trained and required to keep all library routines at a complexity level of 5 on a scale of 10 and easily understood code comments explaining the library function use requirements.  Somewhere during the new wave of software development this rudimental format got lost.   Documentation discipline is not covered is technical school or colleges in design engineering and is left to the individual companies to introduce their method of development documentation.

The challenge is to maximize module reuse and minimize the Total Cost of Ownership (TCO) of devices and equipment from a technical aspect as this series is based on.   The IoT Platform being presented here addresses the latest approach in product development to fine tune the technology and handle the changing business models and companies grow.

When we get to the physical hardware design we will be incorporating design software from Cadence for the schematic capture and PCB layout and Autocad for the mechanical packaging.  We will also present other formats for education purposes allowing the readers to follow with other design software.

When we get to the software development portion of the IoT Platform all routines will be flowcharted along with the appropriate code for the routine.  

As the author of this series I have thought of combining all the separate modules to create an IPD system for the Entrepreneur and have decided to give this an attempt using the document creations for this series.  The requirements are simple it has to interface with current day desktop and web applications easily, that is MS Windows, Linux, and Web Servers.  The use of  MySQL® table format is probably the simplest choice for all its database applications since it is widely used, compatible with many operating systems and open source.  If you want to be part of this, click here to send me a note.

Since this is an educational series, BASIL Networks will be developing a full IPD system for those entrepreneurs that want to develop and manufacturer their own product lines from the processes we create during this series and will be available for downloading along with the Interactive BUS Protocol Development (IBPD) system at the end of the series.  


Part 12  "Preliminary Outline" Embedded Processor Systems Hardware: -Continued

  • Creating Requirements and Traceability Documentation
  • Extracting the specifications from the series to date

More to come in the series

  • Protocol Hardware - Ethernet
  • HS-USB
  • WiFi devices
  • Bluetooth Devices
  • SQI, SPI, I2C,
  • Analog Inputs, Analog Outputs
  • Digital Parallel Ports
  • PWM ports
  • Software tools for embedded processors
  • IDE- Integrated Development Environment
  • Macro Assemblers
  • Compilers
  • Hardware Design Tools
  • and more ....

Reference Links for Part 11:

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory


Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform Development
- Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems-Product Development Management (May 5, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)  
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-11  Product Development Management - (June 5, 2018)

For Website Link: cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=15&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-11 Product Management: <i>Continued (June 25, 2018)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-10

saltuzzo | 04 May, 2018 12:19

Part 10: IoT Core Platform Development - Product Development Management
The IoT Embedded Core Platfrom Documentation Management Introduction

"Learning is not attained by chance, it must be sought for with ardor and diligence." - Abigail Adams

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums(Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems-Vulnerabilities (Mar 16, 2018)
Part 11 IoT Core Platform
- SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018) 
Part 12 IoT Core PlatformIoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)

Quick review to set the atmosphere for Part 9
From the previous Internet of Things Part-1 through Part- 9:

  • (Worth Repeating) - Since the beginning of this series in September 2016 there have been many hacked IoT devices using COTS embedded hardware and software creating high visibility to security and privacy.  The current database of breaches encouraged us to present a more detailed hardware and software presentation to assist designers and educate new comers of the new challenges with security and privacy.  Due to the complexities of processors today we will continue to follow our technical presentation methodology,  Overview → Basic → Detailed  (OBD).   We will be addressing the many sections of the Core IoT Platform separately to keep the presentations at a reasonable length.  The full details will be presented during the actual hardware, firmware and software design stages.
  • The atmosphere has been set for the Internet operation overview in parts 1 through 6.
  • The Ethernet physical protocol is the most used for communications over the Internet.
  • All communications throughout the Internet is performed as UserRouterInternet RoutersRouterUser
  • According to Netcraft there are over 1.8 billion websites active on the Internet that means over 3.6 billion routers minimum.
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • Basic types of CPU architecture on the market today

What we want to cover in Part 10:
Now that the basics on the Internet and embedded processor technology has been presented we are at the time in the series that we have to create the project design management documentation that defines the product we are going to build and market.

We will give a brief summary of how the semiconductor market thinned out as new technology enters the market through Mergers and Acquisitions.

We will indroduce Product Design Management, Project Management, Traceability Management and Asset Management aspects of creating a product from conception to manufacturing.  The links below are the sections of this part of the series.

Lets Get Started:
A Brief summary - Embedded Processor Selection:
Now that the short detour of vulnerabilities have been covered in part 9, we can get back to the business of the Core IoT Platform development.  For this part of the series we will acquire the data required to make hardware selections for the embedded platform development to move forward.  In the previous sessions we mentioned Mergers and Acquisitions and for those who were curious why we bring a business process into a hardware and software design series is that M&A's have a direct impact on product designs as we will see in this section.  Since the series started in September 2016 there have been several important mergers and acquisitions in the embedded market place.  There have been many vulnerability issues directly related to the embedded market with embedded product designs being hacked and causing servers to drop off line from toasters to fish tanks accessing local networks and databases connected to them.

Mergers and Acquisitions are a critical part of product development due to the fact that inventories merge and components of the inventories are discontinued and many times with no replacement component.  This is not a new practice, to give an example, the discrete semiconductor digital logic chips (LSI, SSI) 74xx series IC's were manufactured by several difference independent corporations.  With the introduction of the CPLD (Complex Programmable Logic Device) and the FPGA (Field Programmable Gate Array) the discrete digital chip market dropped in sales over time which caused Mergers and Acquisitions, Texas Instruments, Burr Brown, Fairchild, National Semiconductor and others entered the Mergers and Acquisition process to thin out the market and Altera, Xilinx, Lattice, Cypress and others saturated the CPLD and FPGA markets   These same discrete digital logic semiconductor manufacturers have also entered the embedded market and mostly offer the licensed ARM processor in their own flavors to saturate the market.  There are over 5000 devices to choose from that are offered by various semiconductor manufactures which makes it difficult to just select a few to narrow down the selection process.  

The more M&A's the more the playing field is reduced, so why do we bring up mergers and acquisitions in a technical design series?  Simple- the M&A's throughout the embedded market narrows the playing field and dominates market share.  M&A's also force the end of life of older products as their embedded processor becomes discontinued.  Two major players have emerged from all the M&A's for market share and they are Microchip® and NXP® corporations "at this time frame" and have presented by example the longevity of their products for the embedded markets.

The two that we have selected in Table 10.0 show that their main product line is embedded processors and the secondary product lines support their embedded line.  From a supply chain point of view this puts these companies in the lead for their commitment to the embedded processor market.  Each company has their own line of embedded processors as well as the more common licensed line of ARM processors as shown in the table below.  It is no surprise that ARM processor licensing business model has made an impact on the industry.

32 bit Family

Microchip NXP
MIPS PIC32 X  

ARM 32 Bit

X X
MPC5xxx   X
QUICC(85xx)   X

Table 10.0  Selected Manufacturers to Embedded Processors

Both companies have a unique challenge ahead with their IDE environments.  Microchip MPLAB only supports the PIC line at this time, the Microchip ARM line is supported by the Atmel IDE.  Integrating these two IDE's would be a challenge since they both require a lot of storage and have different Assemblers and compilers.  All the IDE's for NXP as well as Microchip are project oriented type environments.  There are so many embedded processors to choose from and would apply to specific applications that it becomes difficult to just choose a single platform or architecture for a base platform.

The embedded processor market has specific requirements that differ from desktops and servers, that is the embedded processors have to have at least a five year preferably 10 year shelf life which makes Microchp and NXP a likely choice for maturity reasons alone.  The other main criteria pertains to the packaging of the selected processor.  Today many of the IC's are fine pitch and require a class III pcb for reliability and quality in manufacturing, the difference is in prototyping, a FPBGA (Fine Pitch Ball Grid Array) would require an experienced assembly house where a QFP (Quad Flat Pack) may be hand soldered manually and have access to the pins for testing.  Packaging will be addresses in the selection.  

The intent here is to present to the reader how to plan a flexible product line that will evolve by adapting to the changing technology and business models over time to minimize the TOC (Total Cost of Ownership) of a product line.  There will always be M&A's, business model changes as well as technology changes for a faster better embedded processor chip.  With that in mind we will present the best ways to accomplish a core platform that will have longevity and flexibility to adapt to new technologies.

From our market research of the Internet of Things the embedded processor market has been brought into high visibility for the next generation of technology, hence, mergers and acquisitions for market share of embedded processor manufacturers are already starting to thin out the market form the top major players.  Microchip, NXP are the embedded processors major players at this time however, Intel and AMD appear to be entering this embedded market as well even though they have been rolling silicon in the past by entering their past processors in the embedded market the turn in silicon every year keeps them at a desktop, tablet area manufacturer where 18 month life cycles are part of the marketing campaign.  Companies like Microchip, NXP, Altera (now part of Intel), Xilinx, Lattice have all shown a greater than a five year product life and have established the confidence to be incorporated in the embedded devices.

The embedded market anticipated CAGR (Compound Annual Growth Rate)  is about 4% for 2018-2019.  The market size is estimated at about $200+ billion considering the 1.5 Billion smart phones and the 500+ million tablets per year, 15 million cars manufactured along with a few other general markets.  The IoT markets is anticipated to be in the $20 Billion range by 2020.  Companies like AMD and Intel are now entering the market with a different perspective and expect to corner about $10 to $15 Billion segment with their new lines of processors, however both these companies have yet to commit to the real requirements of the longevity of the embedded market, time will tell how serious these companies are.

[Section_Menu]     [Top_Menu]

The Common Hardware of Embedded Processors
Of the few thousand embedded processors to choose from by various semiconductor manufacturers they really do have common internal peripherals regardless of the processor types 8, 16, 32, 64 bit.  All have embedded processor chips, incorporate a variety of unique integrated peripherals and there are a few common peripherals that we will cover shortly.  

The common hardware issue is how these integrated peripherals are brought out to the package pins to interface with the physical environment.  The common practice in place to setup the chips internal peripherals is through a pin configuration matrix that is controlled by configuration registers at initial power on sequence, Boot Time.  Of course analog input and output pins for the A/D and D/A type internal peripherals are connected directly to the pins and are shared always, the digital signals are multiplexed through a matrix selection process.  Figure 10.0 below shows the common embedded processor functional block diagram of how these assignable pins play a roll in our selection.  The Pin Select matrix is unique for each of the processors and the configuration registers for each of the embedded processors, therefore understanding the matrix and how they function is a key performance issue with embedded architecture.  Of course market share is very important to all manufacturers and to attempt to lock in applications they all have a different pin assignment matrix making second source from other manufacturers difficult.

EmbeddedProcessorCommonBlock
Figure 10.0  Embedded Processor Chip Common Block Diagram

The Embedded Processor Selection Criteria "Enigma":
OK, here we go - In the previous parts we identified the protocols and presented different types of embedded CPU architecture.  We will now address this series common environments and characterize the hardware requirements for the Core IoT Platform.  Many developers/designers characterize a specific application for their embedded project, hence a toaster controller, a coffee maker controller, a HVAC system monitor all define a fixed set of I/O functions for the application, therefore defining the hardware for a specific application.  Our Core IoT Platform is intended to be the heart of many different applications and therefore requires outside of the box performance characteristics such that the core is at the highest level of reuse as each application is established.

There is "no single embedded system" that will fulfill all the applications, however they all start with a core platform and grow from there to fit the application.

Technology today allows the designer to be more flexible in determining the full cost of the application.  From a business point of view, the profit margin of a product line has many variables and one of the strongest variables is reuse, therefore the core IoT platform intent is to present the best competitive margin for product manufacturers.  

If you have to maintain a large inventory of different platforms the redesign of any one of them could cost the margin for that line.  If you have a common core a redesign not only saves money and time in the long term but also allows marketing to present a bigger, better, faster mouse trap presentation for maintaining their market share.  Attempting to configure a common platform is a challenge, however not impossible.  We will not be looking at the simple controller for a toaster or fish tank, (not to be used in Las Vegas), since a single chip would handle those applications easily.  The Core IoT Platform for this series requires full Internet security, safety requirements as well as privacy control, which will exceed the majority of single chip applications today.

[Section_Menu]   [Top_Menu]

The Common Issues of Embedded Processors:
We discussed this before and it is always beneficial to keep this in mind when working with embedded systems.  When making a selection of embedded processors for a platform it is recommended that you have a plan B processor to implement when plan A processors is discontinued.  With today's competitive market semiconductor manufacturers attempt to stretch the product line as far as possible which narrows down to less time to redesign a product for the end user or forces a lifetime buy.  The end result is to either end the life for the product line or choose another embedded processor and initiate a redesign to keep the product line active.

Choices to keep in mind:
Choose a set of embedded processors that have the same speed, databus width and the ability of an Extended Bus Interface to run the processor with extended memory if the applications require more memory as many applications probably will.

Manufacturers of embedded processors tend to focus on a specific application arena in order to become the lead supplier in their application market which makes it a bit more challenging to categorize cross manufacturer features with capabilities.  We will only do a few here to set the platform for the cross reference table.  Keep in mind that just because the embedded processor has the peripherals that are common to several others does not mean they will be capable of configuring these peripherals to function the same way or all be active the same way.

Even though the embedded processor is marketed for a specific application does not mean it is only applicable to that specific market area.  The same PIC32 series and the ARM-32 series processor series are used throughout a vast array of applications.  

As stated M&A's have surfaced two major players outside the standard IC (Integrated Circuit) manufacturers and they are Microchip and NXP.  Both companies have the majority of the embedded market share and appear to be making commitments for many years of support by example.  Microchip has maintained its PIC line for beyond the expected lifecycle up to 12 plus years for some of their PIC lines.  NXP published a 10 year embedded device lifecycle guarantee which is a first for public advertising.   Table 10.1 below are just a few of the players in the embedded market that handle 32 bit processors that we are interested for this series core IoT platform.  Keep in mind that this does not cover the entire embedded market however this is a sufficient number of  players for a short list of 32 bit processors.

Manufacture Processor
Series
Speed
MHz
FLASH
Boot
FLASH
Program
Static
RAM
External
Memory
FPU
Microchip PIC32MZ 100-200 >128K >256K >128K Yes Yes
Microchip Cortex A 180-400 >128K >256K >128K Yes Yes
NXP Cortex M 180-400 >128K >256K >128K Yes Yes
STMicro Cortex A 100-300 >128K >256K >128K Yes Yes
Cypress Semi Cortex M 80-200 >128K >256K >128K Yes Yes
Texas Instruments Cortex A 300-1000 >128K >256K >128K Yes Yes
Maxim Integrated Cortex M 80-200 >128K >256K >128K Yes Yes
Renesas Electronics Cortex A 400-1500 >128K >256K >128K Yes Yes
Analog Devices Cortex M 100-240 >128K >256K >128K Yes Yes

Table 10.1  Embedded Processor Manufactures Short List

As we stated prior, not all embedded systems will allow their integrated peripherals to be selected at one time, the "Wild West of Embedded Processors".  The "short list" of companies that we selected from for embedded processors are shown in Table 10.1 above.

When we look at the embedded market it appears that every discrete IC manufacturer has jumped on board with their own flavor of an ARM series processor since it is just a license agreement away.  Looking at distribution and conducting a search for embedded processors - we get a selection of a few thousand chips from various manufacturers.  As we stated the issue in the embedded processor market is longevity for a selected processor chip; the manufacturer of discrete semiconductor IC's constantly fine tune the profit wheel and discontinue parts when they feel that the part will no longer sustain a desired product growth.  

It takes time to recover costs of manufacturing for a product line that uses several IC's and show a profit, if a redesign becomes mandatory too soon then the profit margin will reduce and in many cases the manufacturer is forced to maintain the product line to sustain some form of market share and manufacturer integrity or discontinue the product line.  Will a company keep a product line if it does not sell enough or yield the profit margin they want? the answer is-- wait for it -- HHMmmm "NO".  The common questions that designers have to keep in mind when choosing an embedded processor for a longevity product are the following:

  • The initial release date of the device - this starts the life cycle clock
  • The revision history of the device - This shows the support of the device
  • The roadmap of the device family - this gives an idea of how long it will be active
  • End of Life (EOL) of the device - the LTB (Last Time Buy) notice.

Merges and acquisitions pitched a curve ball into all promises for maintaining product longevity when inventory merging processes begin, usually within the first full year after the merger.  The new questions to be added to the design review list and answered are:

  • Is the device part of a Merger & Acquisition inventory?
  • Does the device compete with the companies standard line before the M&A?
  • Does the M&A roadmap,(if published) sill list the device ?

In any event it would be a fair assessment not to use the products of a M&A until the dust settles or some type of guarantee is established in order to determine if the device selected will have some form of stability for a longevity product.  If the quantities are high enough a separate contract to guarantee a lifecycle of the product could be negotiated.

[Section_Menu]    [Top_Menu]

The Peripherals "Conundrum":
Embedded Processors have several common peripherals integrated on the chip that are industry mature and relatively easy to use within the chip, that is as long as they do not interfere with other peripherals for the same application, hence the peripheral conundrum.  The entire line of embedded controllers on the market today, yes, I stated "entire", allow some type of peripheral configuration methodology, usually pin selection via configuration registers.  The conundrum arises when the selectable pin assignments conflict with the selection of two different peripherals that share the same pin through the configuration register matrix and both are required for the application.  Programmable pin assignments are generally unique to the manufacturer assiduity focused on maintaining their market share and eventually lock users into the manufacturers product line.  This unflagging pin assignment effort is true in the FPGA and CPLD programmable logic manufacturers as well and it is all part of competition and free market enterprise.  The final effect is a sole source device and will always be an issue in a supply chain environment where silicon rollover may easily determine an end users product life if an alternate source is not available.   In order to have a plan B in advance we will look at the common peripherals within the embedded market as well as the common processors to create a reuse plan for our core platform.

For this series core IoT platform we have created a list of common peripherals shown in Table 10.2 that are integrated on many of  the embedded processor chip.  Not all peripherals are integrated in all the selected embedded processors so some would require external peripheral configurations to complete the common platform.

Peripheral Description
Timers Watch Dog for program runtime stability
Counters Standard Binary counters synced to the processor clock frequency
SPI Serial Peripheral Interface
SQI Serial Quad Interface
I2C Inter Integrated Controller
Serial RS 232/422 type interface
Boot FLASH Power On- Initialization program FLASH Average 256K
Program FLASH Runtime Application Program FLASH Average 2048K
SRAM Static RAM for Runtime R/W data Average 16K - 512K bytes)
DRAM Controller User Configurable ( 32Meg - 1024 Megabyte )
Digital Ports Generally Digital I/O Ports 8/16/32 bits
System BUS This is the System Data BUS, Address/Data
   

Table 10.2  IoT Platform Embedded Processor Desired Peripherals

Integrating all these peripherals into a single chip becomes obvious that the package selected will have a direct impact on the number of peripherals that may be active for the application at any one time; running out of pins is a common issue with embedded processors ICs.  This is addressed by programmable pin assignments through a selection matrix controlled by configuration registers to give the best performance for the selected peripherals for an application.  Where it becomes interesting is that just because the core processor is a PIC, ARM or RISC, CISC type processor does not mean that other processor manufacturers that supply a similar or for that point an ARM processor core with the same footprint will assign the same pins or the same peripherals to the configuration registers, hence: again "the conundrum".

Research has shown that there are a few embedded processors that would fit the recipe for this series core IoT platform, they are the NXP 68xxx series (originally Motorola-Freescale line) some will be discontinued also, ARM 32 bit Cortex A, M series, Microcips PIC32MZ series.  Seasoned (older-more experienced) engineers, author included with prejudice, were mentored in the art of design by starting at the "output, problem or need" to be solved and work towards the input of a design, analyzing required results to resources insures that the resources will address the required results.

With all the integrated peripherals on a single embedded processor chip today, it appears on the surface the embedded processor chip could address every possible application know to mankind, however in reality as we stated only a few peripherals may be used at any one time since both pin count and pin sharing configurations will only allow certain peripherals to be part of the real world.   This gets more complicated when we attempt to second source a typical ARM embedded processor chip only to find that all ARM processors on a LQFP-176 pin footprint do not have the same pin assignments.  Since redesign is a high visibility issue today we would like to keep any form of redesign to a minimum as well as Total Cost of Ownership, (TCO) to a minimum as well. .

The short list of embedded processor manufacturers shown in Table 10.1 all have several peripherals in common and are available in common package footprints.  All of the processors have programmable function select registers to allow the Data and Address Bus to be brought out to a select pin assignment defined by the manufacturer for configuring the embedded system as a straight forward CPU chip for adding external components, peripherals and memory.   Figure 10.1 shows the typical mind map process flow we use at BASIL Networks, PLC to determine the package format, common peripherals and embedded processors that may be switched out easily with the least amount of hardware change.   To continue on with the series we selected the LQFP 176 pin package to start, there are FPBGA packages however if the application is to be used in harsh environments the mechanical integrity of FPBGA in the 0.8mm ball and over 300 pads becomes an environmental quality concern,  smart phones etc. not included since the life span is expected to be shorter.

EmbeddedProcessorSelectionMap
Figure 10.1  Embedded Processor Selection Map

[Section_Menu]    [Top_Menu]

The Memory "Dilemma":
The limitations within embedded applications begin to compound when the applications leaves the simple washing machine, toaster or coffee maker application, I was going to add refrigerators until the latest commercial of a refrigerators equipped with a full size touch screen, a database that records everything inside and creates a shopping list and sends it to your smart phone.  It is a easy to get a "clouded" vision of embedded processor applications today.

The standard embedded controller on average comes with 2048K of program FLASH and 512K static RAM that will generally handle single task applications, however, since we are looking at the more complex industrial and commercial arena this configuration will find itself with limitations.  Some have a Memory Protection Unit that incorporated some form of  Virtual Memory with constraints as to the number of virtual task it may perform and the size of the virtual Translation Lookaside Buffer (TLB).  

So as all good technologists we look at extensions to handle the limitations, just add external memory, simple right?  Not as simple as one may think, in fact adding external memory to an existing embedded controller has requirements, compromises and limitations.  The first compromise is pin assignments, address and data pins take up pin resources, especially if you are looking at 32 bits data and 24 bits address, even multiplexed it is still 32 bits data and several control lines which takes clock cycles and reduces performance.  Limitations and compromises come into the picture with how to access the memory and what do we want the memory to be used for, program memory that requires access to the CPU, API storage EEPROM or RAM type data with access through some other form of I/O.

FLASH Memory - Boot, Program, Storage:
To show how sparingly we use memory these days, In the 70's a full Disk Operating System (DOS) actually ran in 4096 bytes and the size of the hard disk was 256K Bytes.  Today "Hello World" with a C compiler takes 16KBytes and that is the link to the Operating System resources it is running on.  It only stands to reason that as applications evolve so will the memory requirements.  

Serial memory such as SPI or I2C are limited in size and speed and generally inefficient to store data or program overlays due to the single serial line I/O.  SQI (Serial Quad Interface) is a bit more efficient and allows larger FLASH sizes as well, however not all embedded processors incorporate the SQI interface.  SQI is also not a choice for program memory since communicating with the CPU requires a direct path and the data would have to be loaded into static RAM to be used by the CPU.  

Boot FLASH that resides internal on the embedded system chips on the above list all have adequate size Boot FLASH greater than 128K Bytes.  For our IoT Platform FLASH is not efficient for fast Read/Write data storage for the simple fact that there is a limited Erase R/W life cycle with all FLASH.  For permanent storage that does not require fast retrieval it would be sufficient.

RAM Memory- Static, Pseudo, Dynamic:
Random Access Memory will be required to read and save real world data temporarily until it can be transferred to data storage via some type of communication protocol.  Depending on the application this could range from 16K Bytes for small transfers up to 32 Megabytes and more for larger applications.  It is advisable to use DRAM if the application goes beyond 4096K bytes outside the normal internal embedded processors memory, mainly for the fact that DRAM uses less pins for addressing and control of memory.  Selecting and incorporating external DRAM is an interesting issue since it requires a DRAM controller that many of the embedded processors do not incorporate.  So we will look at embedded processors IC's that incorporate a DRAM controller and the resources that is used to attach external memory.

[Section_Menu]     [Top_Menu]

Common Embedded Processor Platform:
OK, now that we addressed some of the common characteristics of embedded processor chips it is time to decide on how to implement these common features.  At this point in the development process we have gathered enough information to answer the question of how do we separate this development into sections that will allow the maximum reuse and minimum TCO.

Experience and errors over years gives us a more educated choice on the design direction.  Managing the design is very important and the initial approach has a direct influence of the finished product.  The IoT Platform will be used on-line and security, safety and privacy will be a critical part of the development, therefore traceability has to be maintained throughout the design process.

In order to have a common IoT platform the development direction would be to separate the hardware into categories, hence: the Embedded core processor, external memory and the peripherals which directs the development to a Modular Design Methodology (MDM) which has been used at BASIL Networks for the past 30 years and has proved to be effective and efficient for both hardware and software development.   Isolating the embedded processor chip to a single PCB and defining a standard pin assignment through a high reliable connector platform allows a stable pin assignment for communications between processor and peripherals and addresses the concern of various processor families and footprint pin assignments.

The mezzanine board form factor requirement approach incorporates MDM and will allow the flexibility for the manufacturer to develop an IoT platform for several applications, allow common software and firmware development, reduce peripheral conflict between manufacturers of embedded ICs and much more.

Separating the high priority peripherals required for applications on to a secondary programmable IC, hence: an FPGA or CPLD would allow greater flexibility and reuse especially if the embedded processor IC enters the discontinued device state.  MDM ideology has been around for many decades and applied to many different fields and is widely used today in many electronic devices through out the commercial and industrial markets.

Design of the embedded processor mezzanine printed circuit board for a LQFP-176 is not a difficult project and would allow testing independently.  We will cover the design process for the Printed Circuit Board (PCB) as the series progresses and we enter the physical design stages.  Separating the embedded processor on a mezzanine PCB would also allow other embedded processors families to be designed on separate mezzanine cards from different manufacturers for performance comparison.  Keep in mind, just because the peripherals are integrated does not mean you have to use them.  Using them could have its compromises as well when it comes to performance and programming drivers for them.

The advantages of putting the embedded processor on a small mezzanine board allows the flexibility of replacing the embedded processor while maintaining the peripherals that are critical to the application intact.  This allows the least amount of redesign as silicon rolls over as well as allowing to keep the same processor family which allows the code to be reused as well.  Other mezzanine cards to be considered are the WiFi, Bluetooth and the RJ45 Ethernet that have rolled over silicon many times over the past few years.

Over the years we have experienced with embedded processor the effects of revision cycles when some new added feature removes or does not allow the previous features to be configured the same way.  It is less expensive to rework a small mezzanine board than rework the entire design, this also allows the ease of field revisions if required.

An educational point of view, the mezzaninie board approach will allow the use of the embedded processor the reader is most familiar with, from the hobby market to the industrial COTS market.  Figure 10.2 below is this series approach to MDM mezzanine boards to separate peripherals that are unique to the application and the basic peripherals that are implemented is several embedded processor IC's giving a wider range of selection to fit applications.

IoT_Platform_Mezzanine_Block
Figure 10.2  Embedded Processor Mezzanine and Main Peripheral Block

Rapid development kits are available for many of the embedded system and helps in reducing development time as well as testing unique protocols and application software.  We have a few of the Microchip development cards and a few of the CPLD and FPGA development cards from Altera and Xilinx that we have .  The mezzanine card for the embedded chip is small and compact and easily placed on the main board with a set of micro connectors if small size is required.  For the Fine Pitch BGA devices with 288 pins the embedded chip is only 15mm square by 1.5mm height.  The entire mezzanine card with external memory is only 1.5" square with the full data/address bus at the connector.  Of course the board would be slightly larger for a QFP176 or 208 pin, however the cost of replacing the embedded processor for a redesign is minimal at best using the QFP packages.  The Main Peripheral Board in Figure 10.2 shows that the common peripherals like I2C, SPI etc are just a pass through since most embedded chips do these functions very well and are mature.  However, if pin assignments do not allow these peripherals on separate pins the FPGA is easily programmed to support these peripherals easily as well which will allow common drivers for those peripherals.

Embedded applications are getting more and more complex and the size of the data being processed is also increasing.   Since most embedded systems have a maximum of 2048K of program flash and an average of 512Kbytes of static RAM which is adequate for most standard applications, however for those applications that require continuous data gathering and buffering to transmit the data over a network the use of a DRAM controller and some type of Synchronous DRAM should be included in the core system.

The DRAM controller narrows the selection field at this time, however more and more embedded systems are incorporating a DRAM controllers. Manufacturers also have their own versions and limitations for the DRAM controller as to memory size, DMA, access, transfer speed, memory type and so on.  This also narrows the selection of a large amount of chips to choose from.

The DRAM controller integrated in the PIC32MZ will allow a 32 MB DDR2-400 SDRAM to be directly connected to the chip, if a larger SDRAM memory is required the larger pin count will allow up to 134MB SDRAM memory may be connected and require the LFBGA-288 pin chip.  We will address this again in the next part of the series and weigh the pro's & con's of a separate DRAM controller and memory system for the platform.  

The integration of a GPU (Graphics Processing Unit) in several embedded processor IC's are also surfacing with more capability, these GPU peripherals also take up a lot of pins and limit the other internal peripherals and do require a DRAM controller with external DRAM to obtain the graphics performance.  For the IoT Platform for this series we would like a large amount of internal memory both program and data as well as the External BUS Interface Address & Data BUS to be used for both Program and data.  Graphic embedded systems such as the refrigerator mentioned earlier will be discussed in the applications part of the series.

The DRAM controller does use some of the embedded devices resources, however these devices also come with a DMA controller to accommodate these extended R/W memory and may be accessed through the serial peripherals as well as a few parallel ports allowing for high speed data collection.  If larger amounts or DRAM are required over 134 Megabytes you may want to look at a different category of CPU chips that will support 256MB or higher.  When very large memory size is required a solid state disk may be an alternative as a peripheral device, a physical hard drive is not presented here since it would be easier to stream over an Internet connection to a server or other scaled process systems if available.

[Section_Menu]      [Top_Menu]

Project Management & Requirements Traceability Introduction:
We have introduced the basic discussions for the development of the IoT Platform and for many entrepreneur's and engineers the best part of product development is the real hands on the hardware and software, author included.  However, the critical part of product development is the documentation management system.  Documentation traceability is a critical part of product development that documents all aspects of a product development and vary depending on the type of development, from business to technical.  Product Development documentation is required to insure the successful design and manufacturing implementation of a finished product.  We will cover the basic introduction of the different documentation required to create a product from conception to manufacturing.

Typical business level product development documentation consists of the following sections:

  1. Generating Information  - What kind of mouse trap is it ?
  2. Screening the Idea and Information - Is it a realistic device ?
  3. Testing the Concept - How do we prove it works ?
  4. Business Analysis - Will it be profitable ?
  5. Marketability Testing - How do we test the market ?
  6. Technical Product Details - What are the specifications for marketing ?
  7. Commercializing the Product - Distribution and channel Marketing ?
  8. Pricing and pre-launching - Is the price competitive

Documentation changes when we actually begin the physical design process which involves Computer Aided design systems, Fabrication processes that may be outside the companies resources and have to outsource. Specifications for the actual design of each section of the product that covers interfacing individual subsystems for a completed system product. All of these design functions are separated into different project tasks and require system interface documentation.  So as we see from a simple 8 step business point of view to a multi-function design point of view there are many separate tasks that have to be documented in order to connect all the parts for a smooth product development.  BASIL Networks, PLLC has been in business over 38 years as a small R&D product development service and has developed a Interactive Product Development (IPD) System that we will present here that is similar to the Interactive BUS Protocol Development (IBPD) System presented on the site except it is tailored towards a Documentation Management System (DMS) for Program Management.

There are several areas of the physical product development of the IoT platform that we will address in this introduction:  Product development is generally separated into manageable projects/tasks that are presented in Project Management Timeline or Gantt charts for each section and used to allocate resources and expenses, traceability guidelines for the development.  The Project Management and Requirements Traceability Matrix documentation are considered a living process and grows with the project.  The Project Management software BASIL Networks uses is MS Project as well as the Turbo Project Professional, both handle multiple development tasks easily.  It is always a good idea to plan ahead and categorize internal and external resources for any project, we use our own Calibration and Asset Management system for this that is integrated with BASIL Networks IPD System we have put together over the years.  We will have a version of the IBPD and the IPD Systems on this series for education and reference that may be downloaded as the series progresses into the physical design and testing stages.

The management side of design and development is very seldom presented when discussing technology, however in reality it is a critical component of all design stages in order to incorporate traceability.  Design management is and probably always will be a debate among engineers and managers.  Putting requirements in a matrix form for traceability becomes a management nightmare if not developed early in the process.  The past nine parts of the series we have been laying the ground for the various requirements of the Core Platform prior to actually selecting any hardware, software or form factor, design or testing.  We are now ready to create a starting list of requirements and discuss the process of design management, "Traceability".  Traceability is simple to insure that the process used complies with our security, control and safety-critical policies for the core platform.  Once you decide that the device is to be on-line on a network and/or the application incorporates a safety-critical process, Requirement Traceability becomes a critical part of the management development process. Even a toaster embedded control process has a safety-critical process that is part of a UL or CSA and other agency approval processes which would require a Requirements Traceability Matrix.  Granted for the tinker engineer, design management is put aside for more fun on the bench putting the device together.

The way we have performed this management process varied for BASIL Networks over the years from using Project Management Software to a relational database management system to an enhanced matrix form.  The end results are all the same and essentially becomes part of a Document Management System  (DMS) that is integrated into the companies policy structure.  As an R&D development house we are flexible and generally adapt to which ever methodology being used by our clients.  For this series we will use a Requirements Traceability Matrix  (RTM) form in order to present the RTM creation process as a reference when we enter the interactive design and test stages of the development.  The RTM is a link spreadsheet X/Y that allows the Business Requirements Documents (BRD), Technical Design Requirements (TDR) and what ever other names given to the requirements documents for the application.  

At BASIL Networks our label is TSD (Technical Specifications Document) keep in mind that there are many variations of the RTM's and it is probably one of the most flexible documents and is considered a checks and balance to insure that requirements are fulfilled during the development.  Typical RTM contain the following matrix components referencing or linking the actual documents for the development of a project which makes it easier to incorporate a private controlled Intranet internally for document control.

  • Technical Specification Documents (TSD) - Reference to all Technical Specifications
  • Technical Hardware Requirements Documents (THD) - Hardware Form Factor Specifications
  • Parts Validation Documents (PVD) - Component Parts Validation Documents
  • Software API Requirements (SIR) - Software Application Program Interface specifications
  • Resident Firmware Interface Requirement Documents (RFI) - Resident firmware specifications
  • Test Requirements Documents (TPR- Testing specifications of what is to be tested
  • Test Procedure Documents (TPR- Test procedure specifications
  • Packaging Documents - Shipping and handling  procedures

Many DMS allow a main project document that allows a linking matrix to be used as the RTM during development allowing real time updates.

Development management is very difficult if not impossible to apply the full discipline of the ISO-9000-18000+ procedures during actual development.  Many contract houses follow tight documentation procedures during the design and analysis portions, ISO RHoS parts qualification during prototype development and test for the flexibility of PoC (Proof of Concept) or PoD (Proof of Design).  Engineering prototypes are "experiments" for PoC/PoD and the interaction is in real time and documented is a step by step by hand in an engineering notebook.  

Following strict ISO procedures are great for manufacturing quality control of a product however, experimentation requires a bit more flexibility.  This does not excuse the documentation requirements it just documents the development in an engineering format instead of an ISO format which is more flexible   Once the PoD has been tested and working, transferring the documentation over to the full ISO requirement procedure for formal validation and manufacturing becomes more manageable.  I will probably here from my adversaries about this opinion, however after 37 years as a design house their are processes that are both effective and efficient.

We will create the pro's & con's list of this approach when we put the basics for the platform hardware requirements in table form, yes we will do a SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis, for those that like acronyms SWAT (Strengths, Weaknesses, Advantages and Threats).  Also the creation of a Requirements Traceability Matrix (RTM) will be required for the core platform and the associated applications which we will cover in the series.  At this point we should be realizing that project management and documentation is playing an important roll in the success of this series.  Combining all of these does give an interesting acronyms to play with.

  [Section_Menu]    [TOP_Menu]

SUMMARY:
The embedded processor arena is constantly changing not only the technology but businesses models through mergers and acquisitions which will eventually have an impact on products being developed and availability of components.  This is a common trend with technology and will continue as technology advances.  Older hardware and software are no longer supported forcing corporations to upgrade to keep up.  Just like the rabbit in Alice in Wonderland running just to keep up.  The challenge is to maximize the reuse and minimize the Total Cost of Ownership (TCO) of devices and equipment from a technical aspect as this series is based on.   The IoT Platform being presented here addresses the latest approach in product development to fine tune the technology and handle the changing business models and companies grow.  

When we get to the physical hardware design we will be incorporating design software from Cadence for the schematic capture and PCB layout and Autocad for the mechanical packaging.  We will also present other formats for education purposes allowing the readers to follow with other design software.

When we get to the software development portion of the IoT Platform all routines will be flowcharted along with the appropriate code for the routine.  


Part 11  "Preliminary Outline" Embedded Processor Systems Hardware: -Continued

  • More on Project Management and Requirements Traceability
  • Protocol Hardware - Ethernet
  • HS-USB
  • WiFi devices
  • Bluetooth Devices
  • SQI, SPI, I2C,
  • Analog Inputs, Analog Outputs
  • Digital Parallel Ports
  • PWM ports
  • Software tools for embedded processors
  • IDE- Integrated Development Environment
  • Macro Assemblers
  • Compilers
  • Hardware Design Tools
  • and more ....

Reference Links for Part 10:

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery: http://www.networksorcery.com
The Internet Engineering task Force: IETF - RFC references
Wikipedia https://en.wikipedia.org/wiki/Main_Page

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory


Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4 IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application Continued-The Ethernet Protocol(s) (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application Continued-The CRC-32 and Checksums (Nov 27, 2017)
Part 8 IoT Core Platform Development
- Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Jan 12, 2018)
Part 9 IoT Core Platform Development - Embedded Processor Systems-(SoC)-(SIP) Core Processor -Embedded System Configurations  (Mar 16, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core PlatformIoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-10  Embedded Processor Systems: Core Processor Configuration Development- (May 4, 2018)

For Website Link: cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=15&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-10 Product Management: <i>Continued (May 4, 2018)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

«Previous   1 2 3 4 5 6 7 8  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster