BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B | Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-12

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-12

saltuzzo | 29 July, 2018 14:46

Part 12: IoT Core Platform Development - Product Description Documents
The IoT Embedded Core Platform -Creating Conceptual Design Documentation

"The goal of education is not to increase the amount of knowledge but to create the possibilities for a child to invent and discover, to create men who are capable of doing new things." - Jean Piaget

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 (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 13 IoT Core Platform - Peripheral I/O Development - Device Design From the Beginning (Oct 6, 2018)

 

Quick review to set the atmosphere for Part 12:
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 11.
  • The basic selection of protocols for the IoT Platform have been defined.
  • The conceptual functional block diagram of the IoT Platform has been presented.
  • The internals of the embedded processor IC's peripherals assignments.
  • Documentation categories, requirements, review & creation.

What we want to cover in Part 12:
OK, we have covered interesting technical stuff for the overview of what our IoT core Platform should be.  We got through the difficult review of the documentation requirements for a product development project.  Yes, I know the temptation is still there from the past parts, the excitement and anticipation of just jumping right in and designing the hardware and software on the fly and documenting it later, the consequences have not changes either.

Lets start with putting together the front part of the product documentation for the project - the overall functional blocks that we have to design.  This will give us the guidelines to create specific parts of the documentation for the project and how the documents should interact with the Interactive Product Development (IPD) System relational databases.

Lets Get Started:
The Innovation Process - Starting a New Development Project
The creators / innovators mind-set are all wired differently and face unique challenges in business when putting a product or product line together for development.  The entrepreneur mind-set, the small company mind-set and the large company mind-set, all have their pros and cons.  Regardless be it entrepreneur or company, at the end of development the documentation should be the same prior to entering a manufacturing environment.  The processes are very similar, the conception of the product or product line, the creation of the high level business presentations that sum up the costs and market risk to obtain the business go-ahead, the technical presentations detailing specifications, testing and validation to solidify the budget "expectations" to create Proof of Design (PoD) and Proof of Manufacturing (PoM).  Then the manufacturing requirements presentations for supply chain, manufacturing costs, testing, packaging and build size.  The differences between the entrepreneur, the small company and the large company are the Return on Investment (RoI) statistics, development resources and of course time to market. Prior to the PoD or PoM the only deciding factor is the accuracy of the documentation created to present the project.

For a large company to enter a market arena, marketing has to show the expected RoI that meets the company guide lines for product development.  For a small company the analysis is similar however the RoI numbers are smaller since the overhead is much smaller.  For the entrepreneur it is generally the question of are the overhead bills being paid, what will the initial prototype cost and will the market bring in a profit for a few years.   The documentation process should still end up the same, however less costly for the entrepreneur and small company.

One of the rewards in engineering is the confidence that is built from developing a project from conception to fruition.  Our intent with this series is to build a solid ground for that confidence in all that participate in this development.  There are as many different approaches to innovation as there are those's that develop them.  

The ones I have found to be most useful is being able to map out a 50,000 foot radial mapping of the innovation's core, then breaking down each segment until the detail is adequate for applying to a physical design.  Radial mapping or tree map is centuries old allowing an easy way for the mind to think conceptually Outside-the-Box to organize a multi-tentacle project, which is the closest to a flexible logically, not necessarily scientific approach to create.  Radial mapping over the years has surfaced in many forms such as radial tree maps, fish bone maps, mind maps and many more that the mind may imagine.  What makes this approach interesting is that every individual that incorporates it into their innovation process tailors it to their own mind and that is a key element that unleashes the brain power to move forward with the development.  The capability of the human mind is endless if allowed to think unconventionally.

Conceptualizing a Product:
The conceptual presentation is a very high level "limited detail" type presentation that is generally presented as a first pass to business investors to obtain the proper interest to move forward with the development, short and to the point.  Conceptualizing a project starting point is up to the creator and how the mind is wired for innovation.  Individual minds are all wired uniquely and what ever the starting point is it will usually branch out to connect all the blocks while mapping the project.  As the author the choice is mapping out the high altitude (50,000 foot looking down) functions and working towards the transformations of each segment increasing the details for the actual functions layout, remember this is not the physical design it is the conceptual layout of the IoT system.  Getting from conception stage to the actual development and project management stage is what this part of the series is presenting.

The high level mapping figures are ideal for the business presentation document showing the conceptual overview with enough detail to give an understanding of the actual product or product line.  The process of perspective at this level allows the mind to be more open as we add more detail to each segment.  The process usually takes three or more levels to fully transform from the high level to the detailed level as it becomes more complex for the physical development as we will see.  Assigning names to each level is important for traceability as well as organizational development purposes and allows the Interactive Product Development (IPD) system to be an effective tool for Requirements Traceability Matrix (RTM).  Assigning this as the "IoT_Conceptual_Presentation Document" with a series of sub-levels defined as "Segments" to be easily added to the IPD.

That being said, lets look at our project and start building the documentation to guide us through the development with confidence.  Organizing all the information we covered in the past 11 parts will now be put into a set of documents that will guide us to the successful development of the project.  The IoT Platform as we easily see has many technologies that have to be addressed and interfaced together for a fully functional platform, so lets look at a high altitude view of the projects functional components as shown in Figure 12.0 below.

Figure 12.0 shows the conceptual top segments that will make up the IoT Platform device.  The five high level map segments of the IoT Platform are the basics of the IoT Platform.  Each segment has its own details that we will break down in the following figures.  We will gradually transform the mapping convention to move toward technical details to begin the hardware and software design stages.  Generally at this level the mind already starts to vision the details and plays out scenarios for the platform arranging the detailed sub sections of each segment allowing it to form the product.  This should be easier since we already prepared the mind to conceptualize the product in the past 11 parts of the series.

IoT_Top_Level_Functions
Figure 12.0  IoT Platform Conceptual Function Top Level Segments Map

Radial Mapping The IoT Platform Segments:
The interconnections to the segments are not shown at the highest level in order to give a high level description of each map segment.  This it pass one of the initial IoT Platform outline and may change as we proceed with detailing each segments function for development.  The fixed scientific process would not easily allow backtracking changes which is why Out-of-the-Box flexibility is a true leverage for the entrepreneur and small company, larger companies would have to have meeting after meeting to get pass the required process levels to continue development.  This slide is the "IoT_Conceptual_Presentation - Top Level Segment Map" -Page-1 of the document and consists of the following segments.

The Main Processor Core
The main processor core that we discussed in part 10, Figure 10.2 is used for all the standard operating system embedded functions and book keeping.  There are many applications where only one processor is adequate for all the control requirements, that is not the intent here for our IoT Platform.  It will have the capability to be used in critical infrastructure devices with the maximum security features to prevent hacking.

The Main Core Memory
The Main Core memory is used by the embedded operating system to monitor and control the internals of the IoT Platform.  This memory is not accessible from the outside world and is a supervisory and control memory.  It consists of parallel flash and a general purpose R/W RAM for S&C functions.  The status of the S&C are sent out to the Applications Core Processor for real time updates of the IoT Platform.

The Applications Core Processor
The Applications Core Processor is used for all the applications data from the sensors and other peripherals connected to the IoT Platform.  The ability to add a second processor is dependent on the complexity of the IoT Platforms end application.  If it is a small application then the Main Core Processor may be capable of handling the application functions.  This is usually the case where heavy encryption is not required and communications is generally kept in a closed network.

The Application Core Memory
This memory is used for more complex applications and would consist of a parallel FLASH capable of running the programs directly from FLASH along with some R/W RAM.  Additional storage memory like serial EEPROM if required, otherwise a R/W static or Dynamic RAM would be used for later transmission to the real world.

The Interface Device Segment
The Interface peripherals depend on the type of application the IoT Platform will be used with.  We have talked about having a separate peripheral control processor if the application is very complex and required "fast" real time monitoring & control, otherwise the applications processor may be used if the loop time for the application will fit the timing characteristics of the processor being used.

MAIN IoT Platform Processor Core:
OK, here is where the conceptual presentations takes the first step to transform into the design documents.  It is still a conceptual mapping presentation at this level with a bit more detail for the business to see the depth of the product as a user and not technologists.  

The MAIN Processor Core for the IoT Platform performs the watchdog timer monitoring of the IoT device as well as supports the selected Operating System (OS) that is embedded.  If more than one core is incorporated for the application the main core will handle the communications of the other cores and will incorporate the I/O Memory Transfer Management module for memory to memory transfers between cores.  In a multi-core platform each core will be independent with unique communications between them in order to have different control mechanisms for security and privacy operations.  This slide is the "IoT_Conceptual_Presentation - Core Processor Segment Map" -Page-2 of the document and consists of the following segments.

PICTURE_IoT_images/IoT_TopLevel_MainCore.jpg
Figure 12.2  IoT Platform MAIN Core Processor Segments Mapping

MAIN Startup Routines:
This is the Power-On Initialization or BOOT section of the platform.  This is a sealed part of the IoT Platform and is not accessible to outside influence.  Being in a OTP (One-Time-Programmable) part of the FLASH usually a Top-Boot or Bottom=Boot section of the FLASH depending on the processor core being used and the initial Power-On default Memory access the processor initializes the instruction fetch.  There are many version of a Secure Boot process in many desktops in today's desktops, laptops and smartphones that also have published vulnerabilities.  The simplest way to insure that it cannot be tampered with is to block all access form the power on sequence.  This is one of the reasons the IoT Core processor is an independent entity for the rest of the system and communications is controlled once the boot cycle is completed.

MAIN Operating System Program:
The Main Operating system is also part of the FLASH that contains all the OS's functions and are not alterable.  If you incorporate an update re-FLASH program into the Platform you are now open to vulnerabilities.  This means that the OS has to be well tested and capable of handling many of the features that are to be included in the platform. A TBD (To Be Determined) or a SWAG applied to the software segment in the beginning may cause the development process to exceed budget as well as possibly fail to be completed in a normal time frame.  Putting this on the table up front now will keep the mind-set in place when detailing the development specifications.  Remember functionality requirements are relatively straight forward to organize at today's technology level.

MAIN Hardware Diagnostics Library:
The Hardware Diagnostic library is another important roll in maintaining the functionality of the platform.  To insure security it is requested to uses several different encryption algorithms that includes obfuscating segmentation of the diagnostic firmware in storing it to FLASH to prevent tampering with the code.  This code would be incorporated at the application level of the development in order to perform the applicable diagnostic algorithms for the application.

MAIN Core Processor Physical Memory:
The main core memory would consist of the internal FLASH along with a R/W RAM for temporary functions and a block of  R/W RAM for storage and inter platform communications.  Generally the memory is controlled by the core MMU, however MMU generally have R/W RAM connected to it and also have a fixed number of virtual task and memory protection.  We will look at the ones that allow fixed permanent block for FLASH to be incorporated within the virtual memory block.  If we block this effectively we may not need the MMU at all if we are able to secure the section.

[Section_Menu]     [Top_Menu]

Application IoT Platform Core Functions:
The application portion of the IoT Platform for our development will have its own core processor as shown in Figure 12.1.  This shows both hardware and software mapping blocks for the application segments of the platform.  This is a conceptual mapping of the application segment for any application applied to the IoT Platform.   The common functions are the Internet Protocol Library and the Encryption/Decryption Library segments that will be available to all application programs if required.   A separate MMU (Memory Management Unit) is common for today's embedded single and multi-core processors.  The decision that has to be addressed is should the application have a separate physical hardware processor or should it be a multi-core processor chip?   The Application core processor should include enough memory to handle the interrupt system code as well as some RAM for direct memory access to maintain a steady periodic data throughput to address any time variant data collection and/or analysis.  This slide is the "IoT_Conceptual_Presentation - Application Processor Segment Map" -Page-3 of the document and consists of the following segments.

PICTURE_IoT_TopLevel_Applications.jpg
Figure 12.1  IoT Platform Application Function Segments Mapping

Internet Protocol Library:
The Internet Protocol library are the set of Internet Protocols that this series selected to be incorporated into the IoT Platform.  We put these protocols in the application segment since it would be faster to transfer and process the Internet data from a DMA block if higher throughput is required.  The memory type would be capable of executing instructions directly to the Applications Core Process through the Application memory Management Unit (AMMU).  The library includes the standard Internet protocols, TCP, ICMP, UDP and several others as required by the specific application.

Encryption-Decryption Library:
The Encryption - Decryption methodologies are to be discussed when we get into the security and privacy of the device.  Encryption of data transmitted is a useful tool from Man-In-the-Middle (MIM) attacks that try to intercept data and the URL tags assigned.  There are many algorithms out there like AES256, DES, Elliptical and others that may be applied to this runtime library.

Application Programs:
This is where the actual IoT Platform is applied to the application.  All programs that are used for the application are in this runtime library

Application Memory Management Unit (AMMU):
The Application MMU is part of the dedicated Application Processor configuration and is recommended for memory protection and management..  As stated previously MMU within the embedded market have specific constraints and would be determined by the size of the application. It is added here now in the beginning and may be easily ignored if not required for memory management of the application.  The AMMU handles all the library functions in the library segments, again this library as the others are part of the parallel FLASH and are able to run the tasks directly from the FLASH to the CPU.

Application Core Processor Physical Memory:
The Application core processors physical memory run the real-time applications for the IoT Platform.  The intercommunications between the cores is accomplished via the I/O Memory Transfer Management unit that has a DMA controller to handle direct physical memory to memory transfers.  This block of memory us separated from the Memory Management Unit.  The DMA RAM acts as a real-time data storage area for the peripherals.  The core processor is interrupt driven to handle the several interfaces that it controls.

[Section_Menu]     [Top_Menu]

IoT Platform Peripherals:
Peripherals the main connection to the real world environment as well as peer-to-peer communications.  Many embedded processors integrate several peripherals in order to create a complete application on a single chip.  With the changing technology and the mergers and acquisitions directs us for our platform to keep the peripherals separate from the core device and incorporate a separate processor to handle real-time communications of the peripherals.  There are no direct rules or reasons not to utilize the on chip peripherals at this level except for the discontinuance of the embedded processor chip itself.  The actual application will determine if a separate processor will be required to maintain the application throughput requirements.

For this platform development we will incorporate a separate peripheral processor in order to run the peripherals asynchronously in real time for the maximum throughput and increased control over the peripherals. The peripherals will have a separate BUS structure that is connected to the peripheral processor that will allow the flexibility of incorporating the separate processor or using the core or application processor if the application throughput fits within the processors specifications.

The peripherals interface is a key factor in determining application processing throughput to control the specific application it is designed to control.  This slide is the "IoT_Conceptual_Presentation - Peripherals Processor Segment Map" -Page-4 of the document and consists of the following segments.  This is the last slide of the conceptual presentation and we will put this in a Visio presentation format and incorporate it into the IPD with the filename "IoT_Conceptual_Presentation.vsd". LibreOffice Impress or Power-Point which ever is more suitable to you environment.

PICTURE_IoT_images/IoT_TopLevel_Interface_Map
Figure 12.3  IoT Platform Interface Function Segment Mapping

Devices Core Processor:
Considering today's peripheral complexity it would be advisable to incorporate a separate processor to handle all peripheral communications, that is unless you are just building a simple controller like a toaster.  The Core processor will be very active collecting data and processing the data to the applications processor.   Timing is everything when collecting real-time data for analysis and control.  The peripherals processor could also be part of a multi-core embedded processor chip, however does not have to be.  For longevity the use of an FPGA processor would be efficient and if it is a standard FPGA core processor most  licenses are perpetual and as long as the FPGA is available the designs will remain stable.

Device MMU & Physical memory:
The peripherals memory allocation will vary for by the application, the standard memory within the embedded processor of 2 Megabytes may handle many of the upper level applications.  For Direct Memory Access the PHY DEVICE DMA Controller will control where the data will be passed to.  One of the processors we will be evaluating for this platform allows 134Meg Dynamic RAM that may be uses as peripheral data or program data and allows memory management and protection.

Peripherals are a dilemma in this embedded arena which is why we will evaluate external devices like the FPGA and CPLD for them.  FPGA's and CPLD's are generally CPU independent, however many of today's FPGA's allow a standard 32 bit core processor that may be incorporated as well for total control of the peripherals.  This does answer the argument of discontinued or obsolete processors.

Physical Device DMA Controller:
A DMA controller is also recommended for the peripherals interfaces for real-time periodic data I/O.  The DMA controller is dependent on the applications timing and interface requirements.

SQI & Storage RAM Controller:
The Serial Quad Interface is mainly for SQI FLASH storage since it uses 4 data line and is able to transfer data at faster rates as well as higher capacity than tradition serial devices.   SQI devices are available in both RAM and FLASH from several suppliers.

Ethernet Controller:
The Ethernet controller is the key controller for the IoT Platform since it will be connected to the Internet in some way.   There are a variety of controllers on the market today and some of the embedded processors also have an internal controller in the peripheral block.  We will look at keeping the Ethernet controller independent of the processor in order to have tighter control over the communications process.  We will address the control when we present the security section of the series as well.

Parallel Interface Controller:
The Parallel interface is used for all those other peripherals including straight digital I/O.

Serial I/O Controllers:
All the standard peripherals like serial I/O and parallel I/O have reference designs on line that have been proven over and over again as well as being open source and free to use in a design.  

Software - Firmware Device Libraries:
The Driver library is key to the peripheral performance and if an FPGA processor is selected then the peripherals are all connected internally to the bus and may have a timing advantage as well as a software driver advantage.  There are advantages to creating the I/O Peripheral platform I an FPGA with an internal Processor.   If the FPGA evolves into a new series with more capability, it is easily transferred as has been the case with Altera, Xilinx and many others.  The other advantages are firmware drivers for the peripherals.  Once validate they remain in a perpetual functioning state until the user decides to update them.   Software is still one of the most expensive contributions to the total cost of development and always will be for some time.

[Section_Menu]      [Top_Menu]

Brief Overview of the Interactive Product Development (IPD) System:
As we stated many times during this series that product development of any type requires a unique mind-set and documentation of thoughts and mind-set are essential for a successful product.  What is needed is a Interactive Product Development  system at the project level that is extremely flexible and organized in such a way that creating the documentation is as sequential or random as the individual mind-set that is creating the product.  As we stated there are many categories of documentation during a development project and the IPD addresses these as an open interactive system.  The user can create segments of each layer of the required documentation as the innovation process develops with the flexibility to return to the selected document sections to pick up where left off to continue the development.  OK, a system like this does exist in large companies and takes a while to learn the ins and outs, however as entrepreneurs and small companies we need something less cumbersome and intuitive as well as organizational to use.  

The IPD system main menu has all the different documentation categories that cover all the databases presented as shown in Figure 12.4 shown below, and operates as a project base system.

IMAGE_Databases_of_IPD
Figure 12.4 Interactive Product Development (IPD) System Relational Databases

Project based system architecture is the fundamental organizational rules for development and allows compartmentalization by incorporating separate directories for each project and sub-directories for each category of the project.  The IPD directory structure is shown below in Figure 12.5.

IPD_Directory_Structure
Figure 12.5 Interactive Product Development (IPD) System Directory Structure

Below is the IPD system application programs Opening Dialog to show how the system is organized for easy access of each project category.  The IPD System will be available at the end of the series with added features from readers comments from this series.  There are several Reserved buttons for expansion of the program for those that wish to contribute, send me your request either in a file or message using the Contact Form.  To date this program runs on Windows XP,  Win7.x, Win8.x, and Win10 either directly on the local machine drive or on a server.  Since these are development files and are generally proprietary to the developer it is not recommended to put the development directories on an Internet cloud.  A private in house server with controlled access is recommended if run from a server that is not connected to the Internet.

IMAGE_IPD_TOP_MENU
Figure 12.6 IPD Interactive Product Development System Top Menu

Maintenance Categories

Archive  / Restore

Archive / Restore by Project or full System

DB Tools

Database Maintenance, DB Pack, Create, Move, Copy, Add  etc.

Encryption / Decryption Tools

Full AES256 set of encryption tolls - Not Part of OS

Rich Text Editor

Rich Text Editor for general abstracts of all files saved by IPD system

Component COTS

COTS Components System Library, Resistors, Caps, Inductors, hardware etc.

Components Custom

Custom Components Electrical, Mechanical Project related

Reuse Modules Validated

List of Reuse modules and where currently being used

Products Library Validated

List of Products developed and Modules used

Projects Available

Projects listed in the current Projects Database

Default Directories

Used for initial startup of a project.

Project Related  Documentation Categories and Directories

NEW Project

Create a New Project

OPEN / Edit Project

Open / Edit Existing Project

Presentation Documents

All Presentation Documents by Project

Legal Documents

All Legal Documents by Project

CAD - Documents

All Computer Aided Designs Docs by Project

Firmware & Drivers

All Firmware and Software Drivers by Project

Software API's

All Software Applications by Project

ECO Documents

All Engineering Change orders by Project and Category

Internet Protocols

All Internet Protocols Software

Components COTS

All Components COTS by Project

Components Custom

All Custom Competent by Project

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 and revision traceability.  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.   Revision traceability also pertains to hardware revision, schematics, PCB Layout, Mechanical and assembly control.  The IPD system keeps the current revision a click away and previous revisions in the project level sections keeping them compartmentalized to prevent confusion and accidental release.  Documentation discipline is either not covered or little time is given to the subject in technical schools or colleges in engineering technology and is left to the individual companies to introduce their method of development documentation.


Part 13  "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 12:

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 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 13 IoT Core Platform - Peripheral I/O Development - Device Design From the Beginning (Oct 6, 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-12  Product Development Management - (July 29, 2018)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=17&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-12 Product Management: <i>Continued (July 29, 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

Comments

Add comment

Rest assured, your post or comment has been received, and is simply waiting to be approved. Comments and posts are moderated to prevent spam - this results in a slight delay until you see it posted. Please check back soon. Thank you!

Complete Captcha to add comment 8911314 -Please enter the code shown and click Send.
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster